[Mono-dev] Tuning of assemblies in the mcs module

Jb Evain jb at nurv.fr
Fri Nov 28 10:46:30 EST 2008


Hey there,

Atsushi earlier this week stumbled upon an interesting bug in our
build, which made me think.

The issue right now, is that the build of the `tuner` and the actual
tuning of our assemblies for the net_2_1 (SL2) profile are tied
together.

So the tuner is not built when mono is not configured to build the
moonlight bits, but the tuner is required to build our Mono.CSharp
library which contains our (most amazing) C# evaluator.

A trivial fix would be to separate the actual tuning and the tuner
build, introducing something like csharplib does. We could have a
moonlib, which would trigger the tuning process during the net_2_1
build.

The issue I have with this (and it's entirely my fault), is that we
started building libraries in the mcs/tools module. While we have a
mcs/class module which heh, is for libraries.

The main issue comes from the tuner is a library which references the
assembly `linker.exe`, produces by mcs/tools/linker. This was done to
simplify the life of the .net developers who are simply pulling the
linker or the tuner extensions from SVN. Or maybe only to simplify my
life :)

So my proposal for a correct fix would be to extract a Mono.Linker
library, move it to mcs/class, move the library mcs/tools/tuner to a
mcs/class/Mono.Tuner library, referencing Mono.Linker.

We would also build Mono.CSharp into mcs/class instead of mcs/tools/csharplib.

Then I would add a `tuning` folder in mcs, which could contains
entries for each tuning step, which would be so far, one for the
evaluator, and another one for SL2 libraries.

This sounds the cleaner way to me, but it requires more work than the
trivial fix.

How does that sound?

-- 
Jb Evain  <jb at nurv.fr>


More information about the Mono-devel-list mailing list