Re: [PATCH] support parallel installations

[Gary V. Vaughan]

Alexandre Duret-Lutz wrote:
> On Mon, Nov 15, 2004 at 12:04:07PM +0000, Gary V. Vaughan wrote:
>
> > [[...]]
> >
> > > > +* In order for this to work, Libtool's aclocal macros are not installed
> > > > +  to a shared aclocal dir.  Either change your Makefile.am to use:
> > > > +     ACLOCAL_AMFLAGS = -I /usr/share/libtool-1.9g/m4
>
> This path is system-dependent.  It's a mistake to hardcode it into
> Makefile.am.  Please do not teach people to do that.

Okay.  What about if I AC_SUBST([libtoolmacrodir], [$pkgvmacrodir]) from
LT_INIT, and tell people:

    ACLOCAL_AMFLAGS = -I$(libtoolmacrodir)

> No version of aclocal does support AC_CONFIG_MACRO_DIR presently.  The
> day aclocal does (I'd like this in Automake 1.10), it will not replace
> an additional `-I m4'.  We have to wait for a new release of M4 that
> is able to dynamically change its search path for this macro to be
> completly useful.  Untill then, there should be no difference between
> `-I m4' and `-I m4' + `AC_CONFIG_MACRO_DIR([m4])'.

Forgot about that, thanks.  libtoolize does look for AC_CONFIG_MACRO_DIR
before ACLOCAL_AMFLAGS to decide where to drop its m4 files.  Do you
think that is wrong?

> > > Furthermore, people might just not want to change their package merely
> > > for using libtool.  There should be an easy way to get the default
> > > installed libtool.  I'm not sure yet how to accomplish this.
> >
> > Well, if they want to use libtool-2.0, then they already have to change
> > their configure.ac to use LT_INIT et. al, and I think it better to put
> > the parallel install stuff in now so that they only have to change once.
>  
> I thought you had AU_DEFUN for the old syntax to work?

That's right, but people have to run autoupdate, and then look through
the resulting configure.ac.

> IMHO, it's unhealthy to make such change now, it has too many
> implications and we probably don't realize all of them.  At least you
> should keep a copy of the files in /usr/share/aclocal.  Remember that
> you already tried to remove the m4 files from there earlier this year,
> and it did break many setups.

But how to support parallel installs of various libtool versions with
only a single /usr/share/aclocal?  I'm worried that leaving a copy of
the last-installed-libtool's-m4-files in aclocal is going to cause more
trouble with misunderstood version mismatch errors than cleanly
upgrading to a system that doesn't pollute that directory.

I think it is important to add the parallel install capability as part
of the 2.0 release, because people will hopefully be a little more
prepared for change with a major version upgrade.  Introducing it with
2.2 is more likely to upset people I think.  If we are going to do this
at all, the 2.0 release seems like the best time to introduce it.

That said, I'm all for making it as transparent and backwards
compatible as possible.  Do you have any thoughts on how we can
make it easier on our users?

Remember, we have already gone from saying ``please cat libtool.m4 >>
acinclude.m4'' to ``please remove copies of libtool macros from
acinclude.m4 and use automake >= 1.8 with libtoolize --copy''.  So
upgrading your package from libtool-1.[45].x to libtool-2.0 already
involves a little manual work, and I'd like to make that the only
upgrade that requires manual intervention if I can.

If it is easy to continue to support very old automake releases to
aid piecemeal package upgrade, then I think that is a good idea to
help out our users as much as we can in that capacity.  But it's
not a priority by any means.

Cheers,
        Gary.
--
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature