[Top][All Lists]

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

Re: simplify libtoolize path fiddling [libtool--gary--1.0--patch-11]

From: Ralf Wildenhues
Subject: Re: simplify libtoolize path fiddling [libtool--gary--1.0--patch-11]
Date: Thu, 31 Mar 2005 18:10:09 +0200
User-agent: Mutt/1.4.1i

Hi Gary,

* Gary V. Vaughan wrote on Fri, Mar 25, 2005 at 12:28:47PM CET:
> Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Thu, Mar 24, 2005 at 06:16:33PM CET:
> >
> >>Okay to commit?
> >>
> >>    Most of the hair introduced ostensibly to enable testing of
> >>    uninstalled libtoolize isn't necessary if we allow overriding of
> >>    the libtool master copy directory:
> >>
> >>    * (pkvmacrodir): No need to substitute this.
> >>    * (edit): No need to substitute pkgvmacrodir.
> >>    (dist_pkgvdata_DATA): Use nobase_ prefix so that these files are
> >>    installed to $(pkgvdatadir)/config.
> >
> >
> > Not sure if this will upset people as yet-another backwards
> > incompatibility.  Not if they use `libtoolize', that is.
> Hmm good point.  But are we trying to support mismatched libtoolize vs
> pkgdatadir?  It wouldn't be difficult to fall back from
> $pkgvdatadir/config to $pkgvdatadir if config is missing, but that is
> more hair, which I'm trying to shave off atm ;-)


> My feeling is that if people expect to use mismatched installations of
> libtool,

Not mismatched _installations_.  Old type of use.

> that it would be better for us to notice, and error out rather
> than introduce lots of code to support mismatched installations.  The
> results of running any libtoolize (against it's own installed files) in
> the source tree is not changed by this patch.


Just remember there are people used to just
  cat path/to/aclocal/libtool.m4 path/to/aclocal/other_macros*.m4 > aclocal.m4
  rm -f; cp path/to/libtool/ .
and people who cat m4 files into acinclude.m4 and use `aclocal'...
They will all have to get to know how to use Libtool 2.0+.

We will have to adjust docs to this, and note it loudly.

*branch-2-0 vs HEAD*
> I'll be explicit in future though.  My bad.

Don't worry.

> > This is also still pending the decision whether to put the m4 files back
> > to where aclocal can find them, right?  Will that break all your nice
> > simplifications then?
> Yes it is pending, but I've decided to go with consensus and revert the
> parallel installations patch.  I just haven't done it yet.  No, it won't
> break the simplifications at all, although some of the same lines in
> libtoolize.m4sh will be touched again.


> > It would be nice to see a test case so that one could verify that all of
> > this works.
> Absolutely.  But I can't write any tests for libtoolize until there is a
>  way of running libtoolize out of the build tree.  Originally I
> introduced the -I flag for that, but now this patch allows a test to
> override pkgvdatadir.  If this one goes in, I'll start enhancing the
> testsuite to cover libtoolize too.

That would be great!

Please apply


reply via email to

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