Re: Parallel installs

[Owen Taylor <otaylor redhat com>]

After thinking about this some more, and talking with Tim some,
I've noticed that I was lumping several things together under
the heading of "parallel installs".

First, it is worth distinguishing parallel installs for development
from parallel installs of the runtime.

The things that need to be modified for development are:

 - Library .a libs and .so links (hidden behind gtk-config)
 - Include paths                 (hidden behind gtk-config)
 - -config programs              (user visible)
 - .m4 files and macros          (user visible)

For compilation, the only thing we need to insure is that each
supported API version can be installed simultaneously. There is
no point in allowing parallel devel installs of GTK+-1.3.1 and 
GTK+-1.3.2. What I'm going to do for the compilation environment
is to version the library files to match the way we version
the shared libraries for symbolic versions:

  libglib.la => libglib-1.3.la
  libgmodule.la => libgmodule-1.3.la
  libgobject.la => libgobject-1.3.la
  libgthread.la => libgthread-1.3.la
  libgdk-pixbuf.la => libgdk-pixbuf-1.3.la
  libgdk-x11.la => libgdk-x11-1-3.la
  libgtk-x11.la => libgtk-x11-1-3.la

But for the rest, use 2.0 as the version number:

  $(libdir)/glib/include => $(libdir)/glib-2.0/include
  $(includedir)/*.h => $(includedir)/glib-2.0/*.h
  $(include)/gobject/ => $(includedir)/glib-2.0/gobject/
  $(pkglibdir)/include => $(libdir)/gtk-2.0/include
  $(include)/gtk/ => $(includedir)/gtk-2.0/gtk/

Why not $(includedir)/gtk/2.0/gtk/*.h? Because that would
mean that we would have $(includedir)/gtk including a bunch
gtk-1.2 header files and a single subdirectory containing
gtk-2.0 header files. I also don't know of any other
packages that use such a structure for include files, while
things like db{1,2,3}/ g++3/ python1.5/ are common.

For the more important .m4 macros and gtk-config stuff,
I'm going to name them as: 

  glib.m4 => glib_2_0.m4
  AM_PATH_GLIB => AM_PATH_GLIB_2_0
  glib-config => glib-config-2.0
  gtk+.m4 => gtk_2_0.m4
  AM_PATH_GTK => AM_PATH_GTK_2_0
  gtk-config => gtk-config-2.0

Yes, that's rather long for gtk-config-2.0 - but this stuff
is obsolescent anyways in favor of 'pkg-config gtk2.0'
or whatever.

Now to the runtime - an altogether more difficult question.
The runtime enviroment I can identify for GTK+ is:

 - RC files - from themes, system-wide, and from the user
 - Modules and theme engines
 - .po files for gettext

The reasons why these are more difficult to handle are:

 - Some of this environment is installed separately from GTK+,
   and therefore need to carry over between versions.

   However, modules and theme engines depend on the ABI version,
   so can't carry over between ABI versions.

 - By the way shared libraries work, each time we up the
   ABI version (gtk+-1.3.1 to gtk+-1.3.2), we may leave behind
   programs linked against the old versions, that want the
   old runtime environment.

For the theme engines, I plan:

  $(libdir)/gtk/themes/engines/ => $(libdir)/gtk-2.0/1.3.1/engines/
  ~/.gtk/themes/engines => ~/.gtk-2.0/1.3.1/engines

Since, for theme engines, carry-over across ABI versions is simply
harmful. Yes, gtk-2.0/1.3.1 is a little bizarre, but I don't think too
confusing.

For RC files, we simply need to say that we will always remain
backwards compatible within the GTK+-2.0 once we stabilize.  People
upgrading through the 1.3.1 branch will simply have to deal with the
fact that if theme files change in incompatible ways, then apps linked
against GTK+-1.3.1 will need to be recompiled against GTK+-1.3.2 to
get the new themes.

(Errors in RC files simply cause the rest of the RC file to be
ignored.)

  $(datadir)/themes/Default/gtk => $(datadir)/themes/Default/gtk-2.0

  $(sysconfdir)/gtk/gtkrc => $(sysconfdir)/gtk/gtkrc-2.0
  [ with fallback to $(sysconfdir)/gtk/gtkrc if gtkrc-2.0 doesn't
  exist ]

  ~/.gtkrc => ~/.gtkrc-2.0
  [ with fallback to ~./gtkrc if ~/.gtkrc-2.0 doesn't exist ]

Finally, for .po files, I'm going to change the package for the 
purposes of gettext from "gtk+" to "gtk20". 

This is the part I'm least sure about. The alternative would be to
install the .po files into

 $(datadir)/gtk-2.0/1.3.1/locale/

instead of:

 $(datadir)/locale/

I'm going to go ahead and make these changes and commit them to CVS,
and make a 1.3.1, but I'm willing to change them afterwards if people
have better ideas,
                                         Owen