[Top][All Lists]

[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 (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 
>, 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.



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

reply via email to

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