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
