Hi Stefano, Thanks for the fast response!
On 17 Oct 2012, at 15:52, Stefano Lattarini <stefano.lattar...@gmail.com> wrote: > [Adding Automake list in CC:] > > Reference: > <https://lists.gnu.org/archive/html/autoconf-patches/2012-10/msg00018.html> > > On 10/17/2012 10:25 AM, Gary V. Vaughan wrote: >> >> [SNIP] >> >> I remember many years ago that Tom Tromey (IIRC) stated that aclocal >> was just a stop-gap measure until autoconf could find it's own macros. >> >> I'd *really* like to see aclocal die as a separate program, and have >> autoconf look for (and if requested, copy into the project tree) all the .m4 >> files it needs to generate a configure script. >> > Me too... But aclocal has existed and been used for so many years now that > I think we can't just make it disappear overnight; we'd need a carefully > crafted, documented and publicized transition plan. A fist step might be > to move aclocal out into its own git repository, while still distributing > it bundled with Automake (this could be done for Automake 1.14). But before > starting even to plan for that move, I'd want to be sure that the intended > "replacement" is well underway (that is, designed, agreed upon, and with at > least a semi-working prototype), and that the community is happy with this > transition and committed to help it. I think there is no need for such a cumbersome transition. Instead, I would do it like this: 1. Fold macro search/copy code into autoconf (along with -I argument support) 2. Reimplement aclocal as a wrapper to call autoconf Tools that still use aclocal can do so harmlessly while it is deprecated, but in the mean time everyone can begin to move to a more streamlined build that simply skips the aclocal step. >> No need even for aclocal.m4 >> in that case anymore... the fewer files and tools we have to teach people >> about, the less baroque those people will feel that the Autotools are, and >> the easier the GBS is to understand and learn. >> > Honestly, AFAICS, few people complained about aclocal so far (which sadly > can't be said for automake and autoconf). So aclocal might be annoying for > us to maintain, but doesn't seem a real burden for the users. Most likely because the folks that complain can't distinguish between where aclocal ends and automake/autoconf begins ;) >> I'd have written patches myself long ago, but sadly, Autoconf moved its >> implementation to Perl before I had time to do it :( >> > I honestly believe having an implementation of autom4te, aclocal or automake > in portable shell scripting would be insane. Perl is much, much safer and > easier to use for such "moderately big" programs. Not to mention more > efficient, especially for platforms with expensive fork() like Cygwin. Agreed. Perl was a good choice at the time. I meant unfortunate for me, since after two failed attempts comprising several painful readings of the Camel and Llama books, I finally gave up trying to understand Perl over a decade ago. If it were in a language that made sense to me, I'd have written the patches already. I can sorta kinda still hit Perl code with a hammer, and make it work, but it would be as unreadable to everyone else, as other Perl code is to me. -- And unfortunate for whoever writes the perl patches, since I didn't do it for them ;) At least I can help with the design a bit... Here's a minimal modernish bootstrap script: #!/bin/sh autopoint --force libtoolize --copy --install aclocal # m4 dir from ACLOCAL_AMFLAGS autoconf autoheader automake --add-missing --copy With aclocal search and copy rolled into autoconf, it could look the same, or else like this: #!/bin/sh autopoint --force libtoolize --copy --install autoconf # m4 dir from AC_CONFIG_MACRO_DIR{,S} autoheader automake --add-missing --copy <OFF-TOPIC> If autoreconf were smarter about autopoint and libtoolize ordering, it might even be possible to fold much of the bootstrap script nonsense back into autoreconf, but that's a discussion for another day. </OFF-TOPIC> Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)