Addressing sources dynamically generated by autoconf

[Thomas Jahns]

Hello,

I'm maintainer of a project that needs to sometimes paper over defects in the 
underlying MPI library by interpositioning patched portions of the MPI library. 
The latest instance is one where MPICH mixed up send and receive arguments on a 
specific function and multiple files from MPICH need to be downloaded, patched, 
compiled and linked first into a test program during configure and later into 
our library. We currently use autoconf/automake/libtool and are very happy with 
what that delivers for building our own sources.

The downloaded sources for a defective MPI library on the other hand have a 
different license from our project and therefore cannot be distributed by us.

While installing a fixed MPI library might seem to be the correct way to handle 
the issue, our users are not typically in a position to demand this and expect 
a timely, affirmative response, or their computing time grant might even run 
out before the issue is fixed correctly. Hence, our approach is messy and 
wouldn't be needed in a better world, but so far it's the best approach we've 
found to keep going and not loose too much valuable time.

As is probably obvious from the above, the need to compile such external 
sources is not well covered by automake and it typically expects to know about 
all potential source files ahead of generating the Makefile.
But since we need the build information already during configure to test for 
each defect and if we can "cure" it, I'd much prefer if I could put everything 
into our autoconf macros and only substitute the needed sources into 
Makefile.in later.

The question consequently is: how would I create a Makefile.am that accounts 
for a list of C sources, when the sources are not yet present/known from the 
perspective of automake? I assume problems to mostly stem from the way automake 
derives which rules/variables to include in Makefile.in and how to handle 
dependencies.

For the patches we currently have, I use one block for MPICH and another for 
Open MPI. This worked reasonably well only for a single .c file in each case. 
With the newly discovered problem arises the need to handle multiple .c files 
and also have an implementation that potentially has more than one defect we 
need to treat for a successful run of the test suite.

In summary, I'd really like to keep as much of the complexity in the autoconf 
macros and only substitute a set of generic SOURCES and FLAGS or similar 
variables in a single Makefile.in, preferably generated by automake. The 
currently used Makefile.am can be found here:

https://gitlab.dkrz.de/dkrz-sw/yaxt/-/blob/v0.9.3.1/src/Makefile.am#L201

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.

Since I feel like at a cross-roads for where to go with our current ad-hoc 
method and be a bit more systematic, any opinions/ideas on/for the possible 
approaches is highly welcome.

Kind regards, Thomas Jahns

smime.p7s
Description: S/MIME cryptographic signature