Re: Parallel installs

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> > > also, looking at configure.in now, we now have:
> > > 
> > > [...]
> > > gdktargetlib=libgdk-x11-1.3.la
> > > gtktargetlib=libgtk-x11-1.3.la
> > > [...]
> > >   GLIB_LIBS="$glib_dir/libglib-1.3.la $glib_dir/gmodule/libgmodule-1.3.la"
> > > [...]
> > >   gdktargetlib="libgdk-linux-fb-1.3.la"
> > >   gtktargetlib="libgtk-linux-fb-1.3.la"
> > > 
> > > etc, probably making their way through otehr files (makefiles?) as well.
> > > that is completely unacceptable, i went through great length to hard-code
> > > the version number in really _one_ place only, that is:
> > 
> > To my knowledge - you can't do substitutions in automake target names.
> > If you know how to do that, let me know and I'll make the change.
> 
> i don't understand why you need that at all. for 1.2.x, we produce:
> libglib-1.2.so.0.0.8*
> while using lib_LTLIBRARIES = libglib.la as automake target, and have
> the -$MAJOR.$MINOR version added automatically by libtool through the
> -release $(LT_RELEASE) argument.

-release only effects the soname, not the .a library or .so link.
But we need the libraries to be distinct on the link line.

> the more i think about it, the new scheme appears to be inferior over the
> old one we used (which went through a long process to be perfectly suitable).
> 
> i see that you want to postfix some paths like the one for gtkrc files,
> but i don't get why you need to special-cripple the library and include
> paths here...

If you want to have parallel devel installs in the same directory
heirarchy, then you need to do this.

And I think having the ability to do parallel installs is a significant
win. To repeat a few of the reasons:

 - People don't need separate prefixes to have two devel environments.
   Everybody will need two devel environments for now. Some people
   will need them for a long time after the release of 2.0. Making
   them just work automatically is a distinct win.

 - A distribution can have packages for parallel devel installs, without
   having to install under /opt (which might not have space), or
   doing something odd and non-FHS compliant like putting everything
   under /usr/lib/gtk+-2.0 (Qt does that)

 - We don't have to worry about people accidentally replacing their
   GTK+-1.2 with GTK+-1.3.x and running into problems.

The only problem I'm seeing at all (and not that frequently) is people
who have old GTK+-1.2 compiled versions of fribidi around.

I know that the new setup is considerably more convenient for me as a
developer. I don't have to keep switching around my PATH and
ACLOCAL_FLAGS, etc.

Regards,
                                        Owen