MPI C++ Datatypes: don't declare/define if no C++ support

[jsquyres]

Per MPI-3.1 A.1.1 p674, only define the C++ datatypes if we're actually building C++ support.

Signed-off-by: Jeff Squyres jsquyres@cisco.com

This consequence came out of the "should we define Fortran MPI datatypes in mpi.h if there's no Fortran support?" discussion. In the MPI Fortran WG discussion, it turns out that MPI-3.1 does say that the C++ datatypes should not be available in mpi.h if there's no C++ bindings. The spec unfortunately don't say anything about the Fortran datatypes -- so it'll be brought up in the March 2016 MPI Forum meeting.

This commit removes the C++ MPI Datatypes from mpi.h when there's no C++ support.

@bosilca Please review.

[lanl-ompi]

Test FAILed.

[jsquyres]

Hey @bosilca, the jenkins tests failed -- and with good reason.

I #if'ed out some datatypes in datatype_module.c, which therefore throws off the ordering of the indexing in the datatype array. What's the Right way to do this -- still define the ompi_cxx_ types, but just remove the MPI_CXX_ #define's from mpi.h.in? Typing that out makes it sound like the Right thing to do -- I'll do that. Let me know what you think.

[bosilca]

Removing the defines from the mpi.h is the correct thing to do from the user perspective. However, if we want the entire system to work correctly we should also make sure that the undefined datatypes points to UNAVAILABLE. That being said, this has many implication that have not been foreseen.

1. extern32: table 13.2 provide no support to make some type missing from the standard
2. connecting dynamic processes will not work the way it is defined today, the would be a need for a handshake to see what is supported by the different implementations involved.
3. Manipulating files might become a nightmare if some types are missing. It might even break their compatibility, or force users to always fallback to predefined C types, the only datatypes that are (based on you definition) always available and therefore portable.

[jsquyres]

@bosilca I can mention these concerns in the presentation I'm making at the Forum next week about the corresponding Fortran datatypes issue.

[hjelmn]

:bot:retest:

[gpaulsen]

I like Jeff's suggestion of keeping it it in the datatype array to maintain the indexes, but NOT define them in mpi.h.
I'm okay with all of the "bugs" that George outlined. :) Just get them out of mpi.h!

[jsquyres]

We present this idea to the Forum tomorrow in plenary sessions (i.e., if Fortran datatypes need to exist in mpi.h if there is no Fortran support); we'll see what they say.

[jsquyres]

Straw votes from the March 2016 Chicago MPI Forum meeting are here.

The issue is not fully resolved yet: what should MPI_*_(C2F|F2C) functions return in this case?

[gpaulsen]

bump. Looks like not alot of concensus around MPI_*_(C2F|F2C)?

[jsquyres]

Please add a Signed-off-by line to this PR's commit.

[jsquyres]

Looks like this is not yet resolved in the MPI Forum. Bumped to v3.0.0.

[bwbarrett]

According to Jeff, the forum still hasn't resolved this issue. Next meeting is Jun 14, which is way too late to hit 3.0.0. I'm going to push this to 3.1.x milestone. Someone should bring it back to v3.0.x if they disagree.

[jsquyres]

Looks like there's still a bunch of unresolved questions on this. It doesn't seem that important, and is therefore low priority (as evidenced by this PR being open for over a year with no action). So I'm just going to close this PR without merging.