[MOAB-dev] SEEK_SET again

[Jed Brown]

Jason Kraftcheck wrote:
> Jed Brown wrote:
> 
>  IIRC, your concern when I brought this up before was that some user
>> might expect that behavior when they included the header indirectly.  In
>> my opinion, it's none of MOAB's business to make these sort of decisions
>> for the user.  If it is causing a problem for a user, they should
>> include mpi.h themselves so that they can control it's environment.
>>
> 
> I agree that MOAB should not make such decisions for the user.  That is why
> we do things the way that we do.
> 
> And if they include mpi.h before MBProcConfig.hpp then parsing of
> MBProcConfig will fail because those constants are defined, regardless of
> whether or not we do #define MPICH_IGNORE_CXX_SEEK in MBProcConfig.hpp.  And
> if the application includes mpi.h after MBProcConfig, then
> MPICH_IGNORE_CXX_SEEK will be defined for the mpi.h included by that
> application regardless of what the application expects.

Uh, this is the current state, but not the case if you stripped out the
macro smashing.  Suppose MBProcConfig.hpp just did a plain

  #include <mpi.h>

(not wrapped, no reference to SEEK_*).  Now the user can include mpi.h
in any order with respect to MOAB headers.  If the MPI implementation is
obscure and ignores the issue, and they have already included something
that defined these macros, they will get a compiler error.  Now the
users options are to either smash the macros themselves or define a
macro so the MPI doesn't try to define the MPI::SEEK_* constants.
Either solution will work fine and does not involve MOAB doing anything
special.

The problem case is if they define the macros after including MPI and
then use MPI::SEEK_* in their code (which the preprocessor will replace
with something like MPI::0 causing unexpected behavior).  The present
macro smashing forces this behavior on the user despite more intelligent
handling by the MPI (unless the user manages to ensure that those macros
are not defined when MOAB includes mpi.h, thus circumventing that
wrapping).  (MPICH2 replaces the stdio macros with enums, Open MPI
replaces them with static const int which is friendlier in the presence
of templates, both solutions are better than leaving them as macros
which produces surprising runtime behavior.)

If their MPI can't handle the CXX includes, they can either include MPI
first (so that the C macros are not in scope when the MPI::SEEK_*
constants are defined), or set the correct macros so that MPI can handle
it.  If MPI is set up before MBProcConfig.hpp is included, then a plain
#include <mpi.h> is benign due to the header guards.  The wrapping can
also be removed from MBParallelComm.hpp.

> Perhaps the better solution would be to define MPICH_SKIP_MPICXX.  We
> don't use the C++ API and it seems rather strange to me to include
> that automatically through the C header anyway.

I vote for this, the user can include mpi.h before MOAB if they need the
C++ interface.  I've heard rumors that the C++ interface may be
completely stripped out for MPI-3.

Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20091021/1fed3c3f/attachment.pgp>