[Mono-devel-list] The arrival of the GAC

[Ben Maurer]

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
        mono/stage/$PROFILE/bin.
      * 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
        today's system.
      * One can easily use a staged profile. He would execute:
                export MONO_PATH=$prefix/mono/stage/$profile/lib:$MONO_PATH
                export PATH=$prefix/mono/stage/$profile/bin:$PATH
      * 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
> 	  	  gmcs.
> 
> 		* use gmcs and mscorlib-genreflection.dll to build the
> 		  full mscorlib 2.0 that includes the
> 		  System.Collections.Generics.
> 
> 	  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?

-- Ben