[Mono-devel-list] GAC and third party libraries: post Beta planning.

[Miguel de Icaza]

Hello guys, [Paco, please read until the end]

    This is a follow up to the GAC and third party libraries post from
two days ago.  The situation right now is far from ideal, and we are
trying to find the sweet spot for developers.

    So the problem is: libraries today are installed into the GAC, but
libraries in the GAC are not visible to the compilers.

    How should a compiler reference libraries in this GAC world?  The
solution that we are shipping with today depends on all libraries being
in the same directory as the mcs.exe compiler (gtk-sharp being an
exception, but with the help of a hack we put in the release on the mcs
script, it works for it as well).

    I would like to propose a change to our current setup, which I
think would simplify things. This idea has multiple layers:

	* Using pkg-config
	* Changing our use of pkg-config
	* Adding pkg-config support to the mcs compiler.

* Using Pkg-config to record library locations.

    We have been considering is to encourage developers to only use
pkg-config to specify libraries, so things would look like this:

	mcs program.cs `pkg-config --libs gtk-sharp Robotron`

Or Makefile users would have:

	FLAGS = `pkg-config --libs gtk-sharp Robotron`

	a.exe: a.cs
		mcs a.cs $(FLAGS)

The pkg-config file, uses the link lines from the .pc file installed
for a package, they look like this (this is the one for gtk-sharp).

	PACKAGE=gtk-sharp
        prefix=/mono
        exec_prefix=${prefix}
        libdir=${exec_prefix}/lib
        
        
        Name: Gtk#
        Description: Gtk# - GNOME .NET Binding
        Version: 0.91
        Libs: -lib:${libdir}/mono/$(PACKAGE) -r:glib-sharp -r:pango-sharp -r:atk-sharp -r:gdk-sharp -r:gtk-sharp
        
* Changing our use of pkg-config

   The above works, and it depends on symlinks to be available from the
$libdir/mono/$PACKAGE directory to the GAC.   I would like to eliminate
the use of symlinks (which is also a problem on Windows and for the
Windows installer).

    What I would like to do, is change that that to avoid the
-lib:{libdir}/mono/$(PACKAGE) and instead have the -r: lines directly
reference the assemblies installed, from the GAC:

	Libs: -r:GLIB_SHARP_FULLPATH -r:GTK_SHARP_FULLPATH

Where the  *_FULLPATH are replaced at configure time to the location
where the assembly will reside on the system.   The FULLPATH's could be
obtained from gacutil:

	glib_FULLPATH=`gacutil --probe-name ./glib-sharp.dll`
	gtk_sharp_FULLPATH=`gacutil --probe-location ./gtk-sharp.dll`

This means that by explicitly providing the path to the library to mcs,
we avoid the symlink, and we avoid the new special /package NAME flag
to gacutil.

* Improving the compiler

   A problem that I have with the pkg-config path, is that novice users
need to remember how to use pkg-config, and use back-ticks for output
substitution.   As to me, having read the Unix book by Kernighan and
Pike many years ago, I feel perfectly ok with using backticks.

   But I can just see a teacher, or a book trying to explain that to
compile on Unix, you have to use this particular quote character.  Been
there, seen it, and its not something I want to inflict on Mono users. 

   Instead, I would like to add a new command line option to the
compiler: -pkg:NAME, the use of -pkg:NAME would use pkg-config to probe
for the package name:

	mcs -pkg:gtk-sharp sample.cs

   That avoids the -r: and the -lib: altogether.

* To finish

   I would like to hear people's thoughts on the above proposal, because it:

	* Eliminates the painful symlinks on Windows.

	* Eliminates the need for a central location to expose libraries to
	  compilers.

	* It looks pretty.

	* No replication of libraries

	* pkg-config is the thing to do anyways ;-)

   The downside:

	* Library developers must change their pkg-config files, but that
	  today is a relatively small group of people.

	* Replaces /package NAME with /probe FILENAME in gacutil.

   Also, I would like to hear from Paco, because we could simplify a
lot the life of folks by changing prj2make to support:

	* Installing into the gac.
	* Producing a pkg-config file.

    I love the idea, but are there errors in it?

Miguel.