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
