automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Superseding aclocal?


From: Stefano Lattarini
Subject: Re: [RFC] Superseding aclocal?
Date: Wed, 17 Oct 2012 11:45:31 +0200

On 10/17/2012 11:24 AM, Gary V. Vaughan wrote:
> 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)
>
So autoconf should generate aclocal.m4 itself?  That seems subotimal.  I'd
rather see a clean design in autoconf or even m4 (so done without having to
worry about backward-compatibility); once that is deployed and working, we
could separate aclocal from automake, declare it obsolescent, but keep it
around for backward-compatibility (once we say "this package will no longer
be updated", it stops being a maintenance burden, so we could keep it around
indefinitely, as long as people want to use it).

>   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 ;)
>
While that is true, what I meant is that they report issues that have to
due with their "interfacing" with autoconf and automake (suboptimal or
unclear syntax, m4 quoting problems, unclear error messages, backward
compatibility issues) far more often than they report issues having to
do with aclocal.  Which means that aclocal is fulfilling its role quite
well; and although we developers would prefer such a role not to even
exist, that doesn't concern the users very much IMVHO.

>>> 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}
>
Then we'd at least need a way to emulate "aclocal --install" in autoconf,
since having third-party macro definitions distributed for a more reliable
and predictable build is a feature several users want, independently from
its "implementation details" (that is, whether such a feature is offered
by aclocal or autoconf).  And we'd also need to have ACLOCAL_PATH (or an
equivalent functionality) supported by autoconf ...

>   autoheader
>   automake --add-missing --copy
> 

Regards,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]