[Mono-devel-list] GAC issues and third party libraries.

[Miguel de Icaza]

Hello,

    So we finally gave up with trying to reuse the GAC as the repository
for all libraries at development time, and now the GAC is only a runtime
feature.   Libraries for development are pulled from either directories
referenced with mcs -lib:DIRECTORY or from the directory where mcs.exe
is located (which we have conveniently made a directory where all the
1.1 assemblies live).

    The layout now is like this:

    lib/
	mono/
	   1.1/
		mcs.exe
		System.dll symlink to ../gac/System.version.Pubtoken/System.dll
  	   gac/
		System.version.pubtoken/
		     System.Dll

   Third party libraries would install their software into the GAC
(standard stuff), but we also provided a new command line option to
gacutil: /package NAME which creates a directory under lib/mono called
NAME that holds the symlink to the package, if people want to develop
with it.

   So the layout becomes then:

    lib/
	mono/
	    1.1/
	    NAME/
		Something.dll symlink
	gac/
	    Something.version.pubtoken/
		Something.dll

   This means that developers using third-party packages, say Gtk# have
to do:

	mcs -r:gtk-sharp -lib:somewhere/lib/mono/gtk-sharp hello.cs

   Alternatively, more elite users can do:

	mcs `pkg-config --libs gtk-sharp` hello.cs

   This is not really an issue for professionally built applications,
they will use some kind of automake/autoconf setup to get the values for
gtk# in the first place, but it is an issue for the wild life programmer
who might not be as versed in the Unixisms above.

   A few options:

	* Add a -package: command line option to mcs, so its possible
  	  to do:

		mcs -package:gtk-sharp hello.cs

	  This would add the -lib: to the proper path, and reference any
	  assembly in the gtk-sharp directory.

	  Con: this does not work with csc. 

	* For gtk-sharp in particular (since its a big app of ours),
	  instead of installing it into the "gtk-sharp" child of
	  lib/mono (ie, lib/mono/gtk-sharp), install it on the
	  lib/mono/1.1, so we would get it by "default".

	  Con: its ugly, and wont scale.


   Currently the version number we are using is the `profile' that we
are building, in the case above `1.1' is for the .NET 1.1 profile; 
There is an argument to be made that the above should reflect the Mono
version instead and that we should call it `1.0' or `lib', and version
it in the future.


Miguel.