Sorry for the delay on this -- we ran this idea by all the other
developers and got a resounding "sounds like a good idea!".
So OMPI_MAJOR_VERSION, OMPI_MINOR_VERSION, and OMPI_RELEASE_VERSION
(all integers) will be in mpi.h in Open MPI v1.2. For the v1.2
release, these three macros will correspond to 1, 2, and 0,
If we do a v1.1.5 release, these macros will be in mpi.h as well (as
1, 1, and 5, respectively, of course).
Don't forget that you can always check for the macro OPEN_MPI, too
(it's set to 1 in mpi.h). That's been in there since v1.0.
Thanks for the suggestion!
On Feb 2, 2007, at 6:50 PM, Audet, Martin wrote:
> Thanks Bert for the reply but having these macros in ompi/version.h
> only if a special option is given to configure is useless for what
> I would like to enable in OpenMPI with the present suggestion.
> This is because the whole idea is to make it possible to write
> portable MPI compliant C/C++ programs that are able to chose to use
> or not workarounds for eventual bugs in OpenMPI at compile time
> based on the exact OpenMPI version.
> Declaring the versions macros I suggested would make it possible to
> dectect at compilation if the current OpenMPI version is affected
> by a specific bug and to eventually activate a workaround if
> possible (or terminate compilation with #error preprocessor
> directive if no workaround exists). With the help of the existing
> OPEN_MPI macro these checks could be easilly ignored when using an
> MPI implantation other than OpenMPI.
> And this would be very convenient since the application would
> adjust itself to the OpenMPI implentation without any user
> What I am describing is a common practice. I have checks in my code
> that check for example ROMIO_VERSION or to activate workarounds for
> known bugs or checks for __GNUC__ or __INTEL_COMPILER to activate
> features in newer gcc or icc compilers versions (like the
> "restrict" pointer qualifier).
> But to do similar things with OpenMPI we need these version OMPI_
> macro defined by default in mpi.h. They have to be always defined
> otherwise the save no burden for users.
>> you can build your ompi with --with-devel-headers and use the header
>> #define OMPI_MAJOR_VERSION 1
>> #define OMPI_MINOR_VERSION 1
>> #define OMPI_RELEASE_VERSION 4
>> #define OMPI_GREEK_VERSION ""
>> Audet, Martin wrote:
>>> I would like to suggest you to add macros indicating the version
>>> of the
>>> OpenMPI library in the C/C++ header file mpi.h analogous to the
>>> parameter constants in the Fortran header file:
>>> parameter (OMPI_MAJOR_VERSION=1)
>>> parameter (OMPI_MINOR_VERSION=1)
>>> parameter (OMPI_RELEASE_VERSION=4)
>>> parameter (OMPI_GREEK_VERSION="")
>>> parameter (OMPI_SVN_VERSION="r13362")
>>> This would be very handy if someone discover a bug XYZ and a
>>> for it in OpenMPI versions before (and not including) 1.1.4 for
>>> and wants his code to be portable on many OpenMPI versions and
>>> also on
>>> other MPI-2 implementations. In this situation he could do something
>>> like this in a common C header file:
>>> #ifdef OPEN_MPI
>>> /* true iff (x.y.z < u.v.w) */
>>> #define DOTTED_LESS_THAN(x,y,z, u,v,w) \
>>> (((x) < (u)) || (((x) == (u)) && (((y) < (v)) || (((y) == (v)) &&
>>> ((z) < (w))))))
>>> # if DOTTED_LESS_THAN(OMPI_MAJOR_VERSION, OMPI_MINOR_VERSION,
>>> OMPI_RELEASE_VERSION, 1,1,4)
>>> # define USE_MPI_WORKAROUND_XYZ
>>> # endif
>>> And later in the C source code:
>>> #ifdef USE_MPI_WORKAROUND_XYZ
>>> /* use the workaround */
>>> /* use the normal method */
> users mailing list
Server Virtualization Business Unit