[Mono-devel-list] The arrival of the GAC
bmaurer at users.sourceforge.net
Sat Apr 3 13:31:40 EST 2004
On Sat, 2004-04-03 at 12:48, Miguel de Icaza wrote:
> * What should mono's runtime directory contain?
> The mono runtime directory contains precompiled assemblies
> for bootstrapping.
> Options include:
> * mono/runtime only contains the basics (mscorlib,
> System, System.dll), the rest goes into a more
> complete package `mono-assemblies'?
> * mono/runtime includes all assemblies we support for
> .NET 1.1 (what we do today), and we find a way
> of shipping the other runtimes in a different package
> (.NET 1.0 and .NET 2.0)
> * mono/runtime ships with all profiles compiled.
> * We should have code built into mcs/class/lib/$PROFILE since
> we are now going to support multiple builds.
I will admit I don't know about the packaging aspect of this, so if a
suggestion I make is not possible because of packaging constraints,
please point that out.
The runtime directory has caused me many problems in terms of building.
For example, if you do `make fullbuild' on a clean checkout, it will not
work because of the runtime directory. The dual setup of mcs/class/lib
and mono/runtime just ends up becoming a mess. A major piece of evidence
of this problem is that I often hear the recommendation `just get rid of
the runtime stuff from the makefiles'
So, here is what I would propose:
* The idea of mcs/class/lib is scrapped. This directory is not
used in any form.
* When running autogen.sh in mono, a --with-mcs-path option is
specified. This is a path to the mcs directory. By default, this
path will be ../mcs, which means that cvs co mcs mono will run
without the need to have an extra config option. Not only will
the path selected be made as a variable in the mono directory,
but the mcs directory will also know it (for example, it could
create a file somewhere in build/)
* Inside the mono folder, the following hierarchy is set up:
* stage/ -- this is the root staging directory
* $PROFILE/ -- this will allow each profile an
independent staging area.
* bin/ -- .exe files, as they would be put
into the install path
* lib/ -- .dll files, etc as they would be
put into the install path
* The mcs directory's build system will directly build into the
staging folders above. For the classlibs this is basically the
same as the existing system (but mcs/class/lib is just
mono/stage/$PROFILE/lib). For exe's, this is different in that
rather than mcs.exe going in mcs/mcs/mcs.exe it will go in
* When building the mono/scripts folder, the scripts should go
into each profile's folder.
I think this method would have the following advantages:
* There is one place where binaries go. No syncing between the
runtime/ folder and mcs/class/lib folder exists as it does in
* One can easily use a staged profile. He would execute:
* Each profile's binaries are separated, as you suggested.
* It should be possible for a packager to deal with this. Though,
I would love confirmation on that.
Some open questions with this system:
* I think that extending a system such as the one described above
could be easily modified to create the setup that never
experiences mismatched runtime and corlib during a fullbuild.
Paolo described the correct way of doing it in a reply to one of
my emails (it was the one where he used the magic chainsaw).
Would making such a system the default be worthwhile?
* How much do we stage in the staging area? Right now, I only
thing we need to put in .exe and .dll files generated from mcs
and the wrapper scripts that we generate. However, we could
stage a full prefix in the path, for example we could symlink
the `mono' executable to each profile's bin directory, symlink
libmono.so to all of the lib directories, etc. I often find
myself wanting this, but I am not sure it is really needed.
> * I think we need a single command to build all profiles in
> a single pass: build 1.0, 1.1 and 2.0 profiles on every build.
> I do not think it should be the default for development, as it
> slows things down.
That would make for a great `pre checkin test'. It would also be
interesting to be able to run a `basic regression suite' on each profile
-- something else you could do before checkin. This would probably
consist of the corlib nunit tests, the mcs tests, and the jit tests.
> * Building NET_2_0 is tricky because it requires the generics
> compiler with a corlib that has generics support.
> I think we need to "stage" this build:
> * build .NET 1.1 mcs/mscorlib
> * use mcs to build mscorlib with "reflection.emit"
> support for generics (mscorlib-genreflection.dll)
> * use mcs and the mscorlib-genreflection.dll to build
> * use gmcs and mscorlib-genreflection.dll to build the
> full mscorlib 2.0 that includes the
> We should have a full process that bootstraps the NET_2_0
> profile for sanity purposes.
If we are going to do this, it would be nice get the more common and
probably easier case first: a script to bootstrap CVS from just a
monolite with no intervention :-).
Also, would it make more sense just to distribute a 2.0 monolite?
More information about the Mono-devel-list