[Top][All Lists]

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

Re: [PATCH] support parallel installations

From: Alexandre Duret-Lutz
Subject: Re: [PATCH] support parallel installations
Date: 15 Nov 2004 17:36:08 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.3.50

>>> "Gary" == Gary V Vaughan <address@hidden> writes:

 Gary> 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.

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

 Gary> ACLOCAL_AMFLAGS = -I$(libtoolmacrodir)

Cannot work: autoreconf, libtoolize, gettextize, and autopoint
all parse this line of, and won't digest a Makefile

 >> 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])'.

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

No.  I should have added ", as long as aclocal is concerned." to
my last sentence, that would have been clearer.

 >>>> 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?

 Gary> That's right, but people have to run autoupdate, and then look through
 Gary> the resulting

They *may* run autoupdate.  There are also some reasons they may not
run it:
  - they might not know they need to update (Autoconf's -Wobsolete is 
    disabled by default)
  - they might want to stay compatible with libtool 1.5 during the

 >> 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.

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

Perhaps ask Bruno about this, gettext puts the last copy of its
macro in /usr/share/aclocal/, and I don't know if it has caused
any trouble so far.

I don't think there is anything wrong (at least technically)
with having libtoolize-2.0, libtoolize-2.1 fetch and install
macros from versionned directories.  Simply, you should ensure
that `libtoolize' (unversionned) installs the same macros as
`aclocal' would put in aclocal.m4 since that's how it always
worked and people rely on this.

In that scheme people who want versionned macros will have to
install them in their tree (i.e., not in aclocal.m4).  But this
requirement sounds OK since the feature did not exist in older

Now, although I think it could work I don't like this setup,
because it conflicts with my dream.  OK, I can live with that :)
But let me elaborate on this in case we can share the same dream.

I don't like this setups because it relies on tools (libtoolize,
gettextize, etc.) that we should strive to reduce, factoring
most of their operations into other common parts of the
autotools (like aclocal installing and updating macros).  In my
dream, fooize scripts should not exist.  Of course that's not
going to happen soon, because even if aclocal installs the
macros, there remains the aux scripts.  But it seems good to
think of a solution that work when fooize scripts are not used.
That means you shouldn't rely on fooize-x.y to specify the
version.  As I see it, the version you want to use should be
specified inside, and the right macros should be
selected by updating M4's search patch dynamically based on that
version.  Yes, this cannot be done until we have the new M4.

Another related problem with fooize-x.y is that such tools is
run by hand or from a bootstrap script, but nothing in the tool
suite knows about x.y.  That's not the case if x.y is a entity, as already done in gettext.  Note that
gettext fits well in the dream: you can imagine
AM_GNU_GETTEXT_VERSION being implemented as a macro that
prepends the search path with a versionned directory based on its

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

Is a parallel installation of Libtool needed at all?  
Not meaning to be flip, a serious question.  
Especially since you say:

 Gary> I'm all for making it as transparent and backwards
 Gary> compatible as possible. 
Alexandre Duret-Lutz

reply via email to

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