autoconf
[Top][All Lists]
Advanced

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

Re: questions about AC_CONFIG_MACRO_DIR


From: Stefan Seefeld
Subject: Re: questions about AC_CONFIG_MACRO_DIR
Date: Tue, 12 Sep 2006 12:45:51 -0400
User-agent: Thunderbird 1.5.0.5 (X11/20060808)

Ralf Wildenhues wrote:
> Hello Stefan,
> 
> * Stefan Seefeld wrote on Tue, Sep 12, 2006 at 04:50:40PM CEST:
>> I have just read about AC_CONFIG_MACRO_DIR as a means to
>> specify additional places to look for M4 macros.
>>
>> I notice that the generated configure script still
>> contains traces of that macro, notably, a check for
>> the directory that was given as argument.
>>
>> What is the purpose of this ? Since macro lookup
>> and expansion happens during calls to aclocal, autoconf,
>> etc., there shouldn't be any need for the generated
>> configure script to care, or should it ?
> 
> The idea is that your final package tarball should contain what's
> needed to recreate the generated configure script.

It is one thing for a source package to contain M4 code, but another
to require users to have autotools installed.

> Traditionally, aclocal has been employed to this end: all macros not
> provided by Autoconf itself, or by the package author in acinclude.m4,
> are put into aclocal.m4.  But this was deemed cumbersome: it's not easy
> to update some of the macros in aclocal.m4, for example.  So newer
> Automake have the mechanism that if you have additional .m4 files in
> your source tree that you let aclocal include (for example, by issuing
>   aclocal -I m4
> 
> or equivalently for autoreconf, adding a line `ACLOCAL_AMFLAGS -I m4' to 
> Makefile.am), then aclocal will not copy those macros verbatim into the
> file aclocal.m4, but instead add a line
>   m4_include([m4/macro-file.m4])
> 
> to it.  Much nicer: you can have third-party tools such as libtoolize
> update a file like m4/libtool.m4 instead of having a huge aclocal.m4
> macro with all of libtool.m4 in it somewhere.
> 
> The aclocal from Automake-1.9b works this way, in that you can instruct
> aclocal to install macro files (from, say /usr/share/aclocal-x.y) into
> the directory named by AC_CONFIG_MACRO_DIR, and the libtoolize from CVS
> Libtool recognizes the AC_CONFIG_MACRO_DIR as well and puts its macro
> files there.

I'm not sure why you mention automake. I'm not using automake, or am I ?
(Is aclocal part of automake ? If so, why ?)

I don't want users of the source package to have to touch any of this.
I want them to call 'configure' (which used to be a self-contained
shell script only requiring /bin/sh) and 'make', but nothing else.

>> (The reason I'm asking is that, while the machine where
>> I run autoconf does have said directory, but the machine
>> where I actually configure and build the package doesn't,
>> and so configure bails out.)
> 
> What's the reason for
> - specifying AC_CONFIG_MACRO_DIR, but
> - not shipping the macros in the tarball?

We may be using it wrong (the documentation isn't all that clear,
I have to admit), but as I said, I don't want users to be required
to have the autotools installed, and thus shipping them M4 macros
doesn't seem to make much sense.

Thanks,
                Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...




reply via email to

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