On Wed, Feb 20, 2008 at 06:15:27AM -0700, Jeff Squyres wrote:
> The #defines that are mpi.h are limited to the ones that we need for
> that file itself. More specifically: the majority of the #define's that
> are generated via OMPI's configure are not in mpi.h.
And that's much appreciated.
> Our assumption was that if some other package defined these values, they
> would either likely be coming from the same standard autoconf tests or
> use the same #define conventions as the autoconf tests. As such, the
> values that they are #defined to would be the same (and compilers don't
> whine about multiple #defines of the same macro to the same value -- they
> only whine if the values are different).
The particular offending packages in question are indeed using
autoconf/autoheader, however ompi's defines
#define HAVE_LONG_LONG 1
while the others only
more ac version madness?
> There's two places that would need to be changed:
> - the relevant parts of OMPI's configure script to *also* define an
> OMPI_* equivalent of the macro (which will sometimes mean extracting
> non-public information from the Autoconf tests -- usually a risky
> proposition because Autoconf can change their internals at any time).
> The only safe way I can think of would be to AC_TRY_RUN and write the
> #define'd value out to a temp file. This, of course, won't work for
> cross-compiling environments, though.
> - modify mpi.h.in to use the new OMPI_* macros.
> Keep in mind that mpi.h only has a small subset of the #defines from
> OMPI's configure script. opal_config.h (and internal OMPI file that is
> not installed) has *all* the #defines; that's what's used to compile the
> OMPI code base. mpi.h replicates a small number of these defines that
> are used by OMPI's public interface.
I will think about this guidance and see what kind of patches and
alternative patches I can suggest.
I did not detect autoheader being used in the process of building
mpi.h; is that correct? it would make some simpler workarounds easier.