On Feb 20, 2008, at 9:45 AM, Ben Allan wrote:
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
#define HAVE_LONG_LONG
more ac version madness?
Gaa! Yes, this could definitely be the case. :-(
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.
Correct. We have mpi.h.in in the SVN repository -- it is *not*
automatically generated. We just put the #undef HAVE_LONG_LONG (etc.)
lines in there (which is the same format that autoheader generates),
and config.status will morph these into #define... as relevant.
While I agree that having AC actually define them to a value is a Good
Thing (better than just defining it to be empty), I do see the pickle
that it has put us in. :-\ I don't see an obvious solution.
--
Jeff Squyres
Cisco Systems
