[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