[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] support parallel installations

From: Gary V. Vaughan
Subject: Re: [PATCH] support parallel installations
Date: Mon, 15 Nov 2004 15:11:58 +0000
User-agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)

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 to use:
+     ACLOCAL_AMFLAGS = -I /usr/share/libtool-1.9g/m4
> This path is system-dependent.  It's a mistake to hardcode it into
>  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 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

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.

Gary V. Vaughan      ())_.  address@hidden,}
Research Scientist   ( '/
GNU Hacker           / )=
Technical Author   `(_~)_

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]