Re: [RFC] Superseding aclocal?

[Stefano Lattarini]

On 10/17/2012 05:17 PM, Gary V. Vaughan wrote:
> Hi Stefano,
> 
> On 17 Oct 2012, at 16:45, Stefano Lattarini <address@hidden> wrote:
>> On 10/17/2012 11:24 AM, Gary V. Vaughan wrote:
>>
>>> 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.
> 
> No.  If autoconf can find it's own macros, then there's no need to copy them
> (or m4_include them) into aclocal.m4, which is just an historical 
> implementation
> detail of pre-2.13 autoconf... it will just load the macro definitions from
> wherever it finds them, and (optionally) copy them into 
> AC_CONFIG_MACRO_DIR{,S}
> for distribution.
>
I agree.  That's a reason why we I think can't make aclocal just a wrapper
around the new-and-improved autoconf/autom4te.  Which I don't thinks it's a
problem, since we can just rip aclocal out of automake and let it live as
an obsolescent and mostly-independent package, leaving it available to all
the projects and developers that need it.

> Back in the day, it was easier for Tom to write aclocal inside Automake, which
> he already maintained and have it copy all the macro implementations that
> Autoconf would need into a file that the existing implementation already 
> reads.
>
Makes sense.

>> 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).
> 
> That's true, but orthogonal to teaching autoconf to find macros directly 
> rather
> than looking only in aclocal.m4 and having a separate tool to copy stuff there
> first.
>
Absolutely.  And keeping such things as orthogonal as possible was exactly
my desire :-)

>>>> 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.
> 
> ACK.
>
Happy to hear that :-)

>>> 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 ...
> 
> Good point.
> 
> It looks like the functionality needs to be split between Autoconf and
> Automake, since the files that `aclocal --install` copies are partly for 
> autoconf,
> and partly for the rules Automake writes for make.
>
Actually, not in this case: once ACLOCAL_AMFLAGS is gone, no "aclocal --install"
should ever be run by the automake-generated remake rules; for more background,
see <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9037>.

> Since the two projects already share some infrastructure, I don't see a
> problem in having both tools capable of installing support scripts that
> they require.
> 
> Cheers,

Regards,
  Stefano