[Mpi-forum] Preprocessor Constants

Hal Finkel hal.finkel at yale.edu
Mon Nov 22 21:43:56 CST 2010

On Mon, 2010-11-22 at 18:51 -0500, Jeff Squyres wrote:
> It would be great to see your specific proposal to the MPI-3 Forum.  :-)

I would be happy to write a formal proposal.

> That's both our way of passing the buck back to you :-), and also ensuring that there is a champion to ensure forward progress of each idea that that someone wants to go into MPI-3.  In short: if you want it, either drum up the support and get someone to champion it for you, or champion it yourself.  
> (please note: the above is not meant to be a snide remark.  There are *many* good ideas that we're trying to get into MPI-3.  But there are only so many of us and so many hours in a day.  The best way to make sure *your* idea gets in is to champion it yourself).

Fair enough.

> As noted in New Orleans, you have a bit of a challenge with this idea in that some vendor MPI implementations do not use wrapper compilers, and therefore may have some difficulty in providing this macro.  While we don't mandate specific implementation models in the Forum, we do spend a bit of effort to try to ensure that the standard is implementable in some way in all reasonable environments.  My point here is that we already have implementations where this idea is problematic: can you come up with a way/technique for these problematic implementations to implement your idea?

My personal experience is limited to two kinds of MPI implementations:

1. An implementation which provides wrapper scripts (i.e. mpicc). These
scripts could easily add -D_MPI

2. An implementation which simply documents the flags necessary for
compiling and linking. For example, the documentation might say:
To compile an MPI program, add the following compiler command-line
parameters: -I/opt/mpi/include -L/opt/mpi/lib -lmpi
In this case, the documentation could be changed to say:
To compile an MPI program, add the following compiler command-line
parameters: -D_MPI -I/opt/mpi/include -L/opt/mpi/lib -lmpi

Is there some other implementation style I'm neglecting?

I feel this is similar in style to how POSIX works: the vendor simply
need to document how the user can access a conforming environment. This
would be analogous: the vendor would need to document how to create a
conforming compilation environment. This, of course, needs to be done
anyway (I certainly hope all current MPI implementations document how
the user should compile an MPI program). Either way, the change (in
script or docs) should be small and would not have an effect on existing
user code.


> On Nov 18, 2010, at 6:25 PM, Hal Finkel wrote:
> > Hello,
> > 
> > Appendix A of the current MPI 3 draft (line 45 of page 545) indicates
> > that MPI_VERSION and MPI_SUBVERSION are of type, "const int (or unnamed
> > enum)". This text is identical to that of the the MPI 2.2 specfication
> > (line 45 of page 523), and it should be changed. As the heading on the
> > previous line implies, these should be "preprocessor constants," and
> > must not be "const int (or unnamed enum)". I recommend replacing, "const
> > int (or unnamed enum)" with "integer literal."
> > 
> > Also, regarding the recommendation I made at the SC'10 BOF, I recommend
> > adding the following text after line 19 of page 18 and after line 43 on
> > page 18:
> > User code may assume that mpi.h is unavailable to the preprocessor
> > unless the preprocessor constant _MPI is defined prior to source-file
> > processing.
> > 
> > The practical implication is intended to be that wrapper programs such
> > as mpicc will, in addition to adding the various include and linker
> > flags, also add -D_MPI to the compiler command line. This will allow
> > user programs to:
> > 
> > #ifdef _MPI
> > #include <mpi.h>
> > #endif
> > 
> > in a portable way (analogous to testing for _OMP prior to including
> > <omp.h> when using OpenMP, for example). If the implementation simply
> > documents a set of flags which must be given to the compiler, that set
> > of flags can simply be extended to include "-D_MPI". Since many codes
> > have optional MPI support, this will allow them to use a common
> > preprocessor constant, instead of some codes requiring -DMPI, some
> > requiring -D_MPI, some requiring -DUSE_MPI, some requiring -DHAVE_MPI,
> > some requiring -DHAVE_MPI_H, etc.
> > 
> > Sincerely,
> > Hal
> > 
> > 
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

More information about the mpi-forum mailing list