[Mono-devel-list] GAC Information and Assembly Versioning

[Jonathan Pryor]

I apologize profusely for even mentioning the GAC again, as every time
it comes up a large thread is spawned...  I fear this will be no
different.

First, is there any public document describing the current GAC system,
it's aims, how it works, and how to use it?

In a sense, the first part of this email is an attempt at documenting
some of this, to ensure that (1) I understand what's going on, and (2)
the current situation will actually be documented.

The second part asks a question regarding the current setup and
interaction with assembly versions.

At present, the GAC directory structure appears to be:

	$prefix/lib/mono/<assembly-name>/<assembly-version>/<files>

For example, Gtk# is installed in

	/usr/lib/mono/gac/gtk-sharp/1.0.0.0__35e10195dab3c99f/gtk-sharp.dll

To compile against Gtk#, we can either explicitly use pkg-config:

	mcs my-app.cs `pkg-config --libs gtk-sharp`

Or we can use the new -pkg mcs flag:

	mcs my-app.cs -pkg:gtk-sharp

Which is analogous to the above.

Pkg-config, in turn, refers to files located in:

	$prefix/lib/pkgconfig/<assembly-name>.pc

In the case of Gtk#, /usr/lib/pkgconfig/gtk-sharp.pc.

The pkg-config (.pc) file in turn contains both the required assembly
reference arguments (-r:glib-sharp, etc.) and directories to add for the
search path (-lib:/usr/lib/mono/gtk-sharp).

What's in the library search path?  Symbolic links from:

	$prefix/lib/mono/<project-name>/<assembly-name>.dll

which refer to the actual files within the GAC.  Project-name is a new
construct, grouping related assemblies within the same project.  For
example, the "gtk-sharp" project contains symbolic links for
art-sharp.dll, atk-sharp.dll, gdk-sharp.dll, glad-sharp.dll,
glib-sharp.dll, gtk-sharp.dll, and pango-sharp.dll.  Project-name could
also be the assembly-name, if the project contains only one assembly.

All of this appears to be the case for CVS so far.

Now, the question: how do we handle development against multiple
assembly versions?  Todd Berman first asked this on May 11, and I didn't
see anything that directly answered his question, and the problem didn't
occur to me until recently.

When Mono 1.0 is released, Gtk# 1.0 will also be released.

When Gnome 2.8 is released in September, Gtk# 1.2 will likely be
released.  (Last I heard, Gtk# would try to follow the Gnome Language
Bindings schedule after 1.0, which is tied to the Gnome schedule.)

Consequently, before the end of the year we're likely to have two
different (and upwardly compatible) versions of Gtk# installed on our
machines.

What happens if we want to develop against *both* of them?  It's
entirely plausible that developers will have both versions installed,
but users will have a mix between the two, with some users sticking to
Gtk# 1.0 because they don't have GTK+ 2.4 yet (slow Red Hat 9 users, for
example).

Since the current use of pkg-config presently ignores versions, as the
-lib directory is unversioned, how do we handle this development
scenario?  It seems that we could only have one Gtk# development package
installed at a time.

This might not be too bad, as GTK+ can only have one development version
installed at a time, IIRC.  (That is, you can't have GTK+ 2.2 and GTK+
2.4 development packages installed at the same time, as the header files
will conflict with each other.  Furthermore, some of the headers have
changed between the versions, preventing code compiled against the GTK+
2.4 headers from running on a GTK+ 2.2 system.)

Alternatively, we could version the pkg-config files, resulting in
gtk-sharp-1.0.pc and gtk-sharp-1.2.pc, and each could refer to a
different, versioned, directory in the -lib: argument.  However, this
might be non-obvious, as the command:

	mcs my-app.cs -pkg:gtk-sharp-1.0

would generate assembly references to gtk-sharp.dll.

Do we want to support development against multiple assembly versions? 
If so, how should we support it?  We should probably solve this before
Mono 1.0 is released, as we'll likely run into these issues before Mono
1.2 is shipped at the end of the year.

 - Jon