[Mono-devel-list] [PATCH] Reworked unified Locale classes
Kornél Pál
kornelpal at hotmail.com
Wed Jun 15 04:21:05 EDT 2005
> From: Ben Maurer
> INSIDE_CORLIB is defined :-). You could always look at the commands make
> runs...
I saw it on the command line, but is it safe to assume that INSIDE_CORLIB is
allways defined when mscorlib.dll is compiled and INSIDE_CORLIB is never
defined when any other assemblies are compiles?
>> Please review this patch and approve it if you think so. Otherwise please
>> explain me what should I modify.
>
> I committed something similar to this.
Seems to be good.
It was a good decission to leave Locale.cs of Managed.Windows.Forms alone
yet and to move MonoTODOAttribute.cs along with Locale.cs.
It will be much easier to update the Locale.cs.:)
Two more unneceassary Locale.cs files:
mcs/class/System.Data/System.Data/Locale.cs should be deleted as it is not
used.
mcs/tools/resgen/Assembly/Locale.cs should be removed and
mcs/build/common/Locale.cs should be used instead.
> RelPath = "../../build/common/Locale.cs"
> RelPath = "../../build/common/MonoTODOAttribute.cs"
> will fix it. Otherwise, you can always have a makefile target that will
> copy the files if it is on a windows box or something. If we are going
> to have a serious i18n framework, it's going to be extremely painful to
> force people to copy and paste the code like that.
VS.NET cannot load project files unless they are inside the project
directory so a makefile modificatio seems to be the solution. Currently,
when Locale.cs usually had only method in Locale.cs there were 7 variants
and this would grow to more if we let them separated. So I think this
disadvantage (VS.NET project) is worth for the benefits of a single copy.
Kornél
More information about the Mono-devel-list
mailing list