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

[Francisco T. Martinez]

[Todd and Miguel, please read until the end]

I have a couple of observations and some in-line comments in the body of
the original message below.

Just want to stress that the direction in which some influential
thinkers in Microsoft want to go is away from the Windows registry and
to use GAC as sparsely as possible.  The prefer approach is the "xcopy"
installation of already compiled assemblies.  My full time employer has
been doing .NET development (primarily ASP.NET) for more than a year now
and we have only found two justifiable instances where a given
"enterprise wide" component had to be "gacked".  

Just to be complete, there is also the configuration file (eg,
"myApp.exe.config") and the properties that can be specified to find
assemblies during runtime. I recently participated on an in depth .NET
Framework course given by Jeffrey Richter of Wintellect. In this course
the configuration information file was exalted as an alternative option
to GAC registration -- more on these at the bottom.

"http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconHowRuntimeLocatesAssemblies.asp"

On Wed, 2004-05-05 at 12:55, Miguel de Icaza wrote:
> 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.
> 
I think that after reading all of the post on this very active thread,
the one idea that got the least attention must be the compiler
enhancements.  

I am partial to this approach.  It has already been established that our
implementation of the GAC has differences from that of Microsoft. 
Perhaps the fact that we have our own binary, mcs and we don't use csc
has added somewhat of a case to innovate the way that Miguel suggest.

I also think it offers one of the cleanest "hands off" approach from the
developer standpoint.

> * 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?
I will get to work on adding the necessary support in prj2make# and
prj2make-sharp-lib as soon as the final approach is decided.

Maybe a new capability that may serve both Mono and MonoDevelop would be
to have the prj2make# family produce configuration files like the ones I
talk about at the beginning of my reply as well as pkg-config files --
which I thought was also very interesting and useful!.
> 
> Miguel.

Paco