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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
