Re: [RFC] Superseding aclocal? (was: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal)

[Gary V. Vaughan]

Hi Stefano,

Thanks for the fast response!

On 17 Oct 2012, at 15:52, Stefano Lattarini <address@hidden> 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)