autoconf
[Top][All Lists]
Advanced

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

Re: including files in configure.in


From: Ralf Wildenhues
Subject: Re: including files in configure.in
Date: Thu, 8 Jun 2006 11:01:06 +0200
User-agent: Mutt/1.5.11

Hello Theodore, Micah,

* Micah J. Cowan wrote on Thu, Jun 08, 2006 at 12:48:59AM CEST:
> On Wed, Jun 07, 2006 at 02:54:35PM -0700, Micah J. Cowan wrote:
> > On Wed, Jun 07, 2006 at 01:31:43PM -0700, Theodore Sternberg wrote:
> > > Is there a way to include external files in configure.in?  In the
> > > interest of being modular, of course.

The idiomatic way of doing this is writing Autoconf macros (with
AC_DEFUN) and putting them in macro files (for example named m4/foo.m4),
and letting those be found by 'aclocal -I m4', and calling those macros
in configure.ac.  And installing the more-useful of those macros into
the system-wide aclocal directory for other packages to use.

> > > I'm thinking along these lines:
> > > 
> > > case "${host}" in
> > >         *86*-linux-gnu*)
> > >             include linux.generic
> > > 
> > >         x86_64-*-linux-gnu)
> > >             include linux.generic
> > >             include linux.64
> > > 
> > >        [...]
> > > esac
> > 
> > m4_include([linux.generic]) works for me.

Yes you can do that.  But no, it's not the Typical Autoconf Way[tm].
Typical would be to test for features, not for system types; the latter
often turn out to be more maintenance-intensive, or even much more so,
so should be used only if the former are not possible.

That said, using m4_include is better than sinclude/m4_sinclude, as
it will be possible for autom4te to see the file dependencies, and it
will correctly regenerate configure if any dependencies have changed.
(Otherwise, you'd have to remember to wipe autom4te.cache/ before
running autoconf, or customizing autom4te configuration to not use it.)

> > You should be able to use the GNU m4 manual as a reference, remembering
> > to prefix all builtins with m4, and checking autoconf's manual for
> > additional information.
> 
> Actually, now that I think about it some more, it's probably more
> efficient to attempt to use the /shell's/ inclusion instead, via the
> "source" command or somesuch. But then, I have no idea how you would get
> autoconf to process linux.generic.{ac,in} to linux.generic... you
> probably can't.

Shell inclusion happens at script execution time (./configure time)
so if you want to support VPATH builds (source tree != build tree),
you need to make sure to use $srcdir.  And rightly, the included script
won't be treated by autoconf at all.

The difference in efficiency should be completely negligible for modern
shells (unlike ancient shells, such as Solaris' /bin/sh; but you don't
want to optimize your scripts for those, unless you have a desire to go
mad over time).

> Barring that, you should avoid invoking m4_include() more than once on
> the same file, even "conditionally". NB that simply replacing your
> includes above with m4_includes will cause the entire contents of
> linux.generic to be imported into your configure script /twice/.
> Instead, you might want to set a flag in both linux options, and check
> for that flag after the case statement, at which point you'd do the
> /actual/ inclusions.

Oh, I wouldn't worry about a duplication if the included file is small.
Let's worry about big duplications only.

> Better yet, I'd imagine you can achieve your goals more efficiently by
> defining custom macros in your aclocal.m4 (or acinclude.m4, if you're
> using Automake), and simply invoking the appropriate ones. This really
> removes any usefulness of sourcing other external files, as far as I can
> tell.

Right.  Much much better.  Except I wouldn't stuff all macros into
acinclude.m4, because updating them is more work then.

Cheers,
Ralf




reply via email to

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