[Mono-devel-list] And something more about corecompare

Miguel de Icaza miguel at ximian.com
Sat Jul 12 17:29:33 EDT 2003


> whoever updates the corecompares on the webpage. Are you sure you
> compile the Assemblies with the NET_1_1 or at least NET_1_0 symbol?
> Because the code I wrote and that is included in NET_1_1 symbol checks
> does not seem to be taken into account in corecompare.

Hopefully this weekend we can get Peter's fantastic new build system
deployed on CVS.  The new build system will help do things like do the
two different builds (NET_1_0 and NET_1_1 and also the various ECMA
profiles: kernel, extended and even more).

Once this is done, we will revisit the issue.  Today we build the
libraries without any symbols.

> Also is it possible to do such updates a little more often or at least
> a little more regulary (once/twice a week maybe). And are you planning
> to add corecompare entries to the webpage for all assemblies to the
> webpage. There are missing some currently (like System.Design or
> System.Drawing.Design or...)

Some assemblies actually break corcompare, which is why we did not
update those for a while (CorCompare aborts when loading some

Today we run CorCompare on Windows and compare the Windows assembly and
the Mono assemblies, and this for example is the source of not updating
the website more often, because it requires a working Linux/Windows
combo setup to update (for other more complicated reasons as well).

Ideally, we should change the setup to copy the original Windows
assemblies to Linux (since Mono does not crash like .NET does while
loading these assemblies).  This is a relatively simple fix for the

There is a final issue though: today the user interface for the showing
the status of the assemblies assumes a unique build.  With the arrival
different sets of profiles (NET_1_0, NET_1_1, ECMA, etc) the solution is
sub-optimal, and we should think of a way of dealing with this.


More information about the Mono-devel-list mailing list