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

[Gary V. Vaughan]

Ralf Wildenhues wrote:
> Hi Gary,

Hallo Ralf,

Thanks again for the review!

> * 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 ;-)

My feeling is that if people expect to use mismatched installations of
libtool, 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.

>>      (pkgvmacro_DATA): Renamed to...
>>      (nobase_pkgvdata_DATA): ...this, so that files are installed to
>>      $(pkgvdatadir)/m4.
>
>
> So this tells me your patch is against HEAD.  Please write that upfront
> so I don't need to kill my branch-2-0 tree.  Thank you.  (I previously
> thought libtool--gary--1.0 was branch-2-0 and libtool--devo was HEAD?)

Oh, sorry.  Arch terminology category--branch--version, where I'm using
version to denote which CVS branch and branch to denote the arch branch.
libtool--devo--1.0 is HEAD, libtool--release--2.0 is branch-2-0, and
libtool--gary--1.0 is my scratchpad branch from HEAD.  If I wanted to do
development on branch-2-0 I'd create libtool--gary--2.0.

I'll be explicit in future though.  My bad.

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

>>      (install-data-hook): Adjust.
>>      * libtoolize.m4sh: Remove -I processing.
>>      (func_filename_path_search): No longer required without -I.
>>      Adjust all callers.
>>      (pkgvltdldirs, pkgvmacrodirs): Deleted.
>>      (pkgvdatadir): Allow overriding from the environment so that we
>>      can write tests for uninstalled libtoolize.
>>      (func_serial_update, func_ltmain_update, func_config_update):
>>      Rename srcdirs parameter to srcdir, and don't call the path_search
>>      function anymore.  Adjust all callers.
>>      (--install): Don't blindly copy all config files.
>
>
> 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.

> Other than above, I noticed that a `make uninstall' leaves quite a
> number of files behind -- all of libltdl -- but that is orthogonal to
> this patch.

Thanks, I hadn't noticed that.

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