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

[Ralf Wildenhues]

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:
> >>
> >>    * configure.ac (pkvmacrodir): No need to substitute this.
> >>    * Makefile.am (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 ;-)

Yep.

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

ACK.

Just remember there are people used to just
  cat path/to/aclocal/libtool.m4 path/to/aclocal/other_macros*.m4 > aclocal.m4
  rm -f ltmain.sh; cp path/to/libtool/ltmain.sh .
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.

OK.  

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

Regards,
Ralf