Re: Addressing sources dynamically generated by autoconf

[Russ Allbery]

Thomas Jahns <jahns@dkrz.de> writes:

> I know I can write a Makefile.in myself, but given the number of
> additional targets users expect, I'd really prefer sticking to build
> instructions as much as possible and delegate dist, check and other
> targets to automake. I also know about AC_LIBOBJS, but this facility
> only seems to address a list of sources I can provide in a verbatim way
> and not necessarily via some macro or shell variable even, but I'd like
> to be wrong about that.

AC_LIBOBJ feels like the right mechanism to me, but perhaps I don't
understand what you're trying to do.  It does seem to do exactly what you
are talking about, though: substitute in additional sources based on
Autoconf results without having to list them explicitly in Makefile.am.

I think the problem you may be running into is that AC_LIBOBJ requires
that the file name you give it as an argument be a source file that is
included in the distribution tarball, whereas you want to generate that
source file on the fly.  But you can work around that with a bit of
trickery.  Suppose that you have some probe that conditionally calls
AC_LIBOBJ([mpich-fix]) based on whether you detect that there's a problem.
You can then include mpich-fix.c in your distribution tarball as a
one-line file that contains only:

#include "mpich-fix-real.c"

mpich-fix-real.c is *not* included in your distribution tarball.  If the
configure check succeeds, this file is never added to the sources and thus
is never compiled and the fact the file doesn't exist doesn't matter.  If
the configure check fails and you need to fix something, then configure
generates the file mpich-fix-real.c on the fly, Automake adds mpich-real.o
to LIBOBJS/LTLIBOBJS, and the compiler follows the #include and builds
your generated code.

Does that get at the problem that you're having?

-- 
Russ Allbery (eagle@eyrie.org)             <https://www.eyrie.org/~eagle/>