bug-automake
[Top][All Lists]
Advanced

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

Re: aclocal flags are a pain


From: Behdad Esfahbod
Subject: Re: aclocal flags are a pain
Date: Tue, 16 Sep 2008 17:53:49 -0400
User-agent: Thunderbird 2.0.0.14 (X11/20080501)


Ralf Wildenhues wrote:
> Hello again,
> 
> * Behdad Esfahbod wrote on Tue, Sep 16, 2008 at 01:40:41AM CEST:
>> To use an m4/ dir one has to modify three places:
>>
>>   * autogen.sh: add "-I m4" to their aclocal invocation (ok, I know 
>> autoreconf
>> prolly handles it),
> 
> Yes, it does.  What keeps you from using it?

Well, in some projects grumpy other maintainers that are against change in
general.  In others, because we have to run some other stuff too anyway (like
gtkdocize for example), so we use gnome-autogen.sh for example.  Also for more
flexibility.  For example, we try glibtoolize before libtoolize.  That's
needed on OS X.  Perhaps autoreconf does that already.

Reading autoreconf source right now.  I may just switch to it if my testers
tell me it works on OS X and msys.


>>   * configure.ac: add AC_CONFIG_MACRO_DIR(m4)
>>
>>   * Makefile.am: add ACLOCAL_AMFLAGS = -I m4
> 
> Again, flexibility: for example gcc in its tree has things like
>   ACLOCAL_AMFLAGS = -I ../config -I .. -I .
> 
> but its AC_CONFIG_MACRO_DIR is empty in some directories, and m4 or
> ../config in others.
> 
>> This makes no sense.  aclocal should scan configure.ac and pick up the flags,
>> and automake should use the configure.ac stuff to generate the correct 
>> aclocal
>> rerun rule.
> 
> Hmmyes, this sounds like a better default than what we have now.
> After all, a user that needs to override it can still set
>   ACLOCAL_AMFLAGS =

Exactly.  The same way that AM_INIT_AUTOMAKE and AUTOMAKE_OPTIONS interact.

> Lemme think about this one.
> 
> Thanks,
> Ralf

Cheers,
behdad




reply via email to

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