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

Todd Berman tberman at sevenl.net
Wed May 5 21:10:56 EDT 2004


I dont see how the /probe replaces the need for /package.

You still have one of the issues that caused the need for /package in
the first place (Different versions of the same assembly). It seems that
it wouldn't replace it at all, but compliment it.

We still have a (imo) huge issue with regards to prefixes. I think this
can be fixed by reversing the direction of our symlinks (instead of from
$prefix/lib/mono/package/blah.dll to the real gac'd assembly, symlink
the other way around). This will remove the need for some kind of hacky
MONO_GAC_PATHS or something evil like that, as regardless of what prefix
your libraries are really on, you would have them all symlink'd to the
proper place. Of course, then you get into typical issue of touching
files outside of the user requested prefix, and auto* distchecking, and
that general unix nightmare.

Just some random thoughts (most likely not too coherent)

--Todd

On Wed, 2004-05-05 at 13:55 -0400, 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.
> 
> * 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.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list




More information about the Mono-devel-list mailing list