Am Mit, 2002-01-16 um 18.06 schrieb Havoc Pennington: > > Jens Petersen <[EMAIL PROTECTED]> writes: > > -m4datadir = $(datadir)/aclocal > > +m4datadir = $(datadir)/aclocal-@VERSION@ > [..] > > So if the change is done this way, we need a commitment from the > autoconf maintainers that share/aclocal macros will never break with ^^^^^^^^ ^^^^^^^^^^^^^ autoconf automake!
> new autoconf, which I think is a silly commitment to expect, ergo I > would personally go with putting the interface version (just the > "1.4") in share/aclocal-1.4 and encouraging third party macros to go > in there. Or perhaps it's more appropriate to use an autoconf version > in the name e.g. share/aclocal-2.5x or something. 1. IMO, using the autoconf's version number would be appropriate, because third-party share/aclocal/+.m4s are configure-script fragments, therefore are subject to autoconf compatibility and only marginally related to automake at all. 2. I am not sure if recommending share/aclocal-<version> for third party macros is a good idea: * Currently hardly managable on the user-side => If at all, then some auto*tool should installing *.m4's to share/aclocal-<version> automatically (data_ACLOCALS = foo.m4 ??) * share/aclocal macros can be (and currently are supposed to be) compatible to several versions of auto*tools. Installing third party macros to aclocal-<version> would unnecessarily tie these to a particular set of autotools and raise further problems if later used with other packages' configurations. 3. I would prefer to put automake's own macros (which are likely sensitive to incompatibilities between different versions of automake) into share/[automake|autoconf]-<version>/aclocal. This would completely decouple third party and automake's aclocal*.m4s. 4. People should learn to apply autoupdate on share/aclocal/*.m4s. > Anyhow, let's stop overcomplicating the problem. There are very few > names that matter: > > datadir/aclocal-whatever > bindir/aclocal-whatever > bindir/automake-whatever + datadir/aclocal > Just make them change when and only when they break. There's no rocket > science involved, just details, but the available choices for the > details should be clearly defined. This stuff ain't as easy as you might think, believe me :) Ralf
