Jed, my 0.02US$
we recently had a kind of similar discussion about MPI_DATATYPE_NULL, and we concluded ompi should do its best to implement the MPI standard, and not what some of us think the standard should be. in your configure script, you can simply try to compile a simple fortran MPI hello world. if it fails, then you can assume fortran bindings are not available, and not use fortran types in your application. Cheers, Gilles On Tuesday, February 9, 2016, Jed Brown <j...@jedbrown.org> wrote: > George Bosilca <bosi...@icl.utk.edu <javascript:;>> writes: > > > Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As > these > > languages are interoperable, and there is no explicit conversion > function, > > it is safe to assume this is the case. Thus, is seems to me absolutely > > legal to provide the MPI-required support for DOUBLE PRECISION despite > the > > fact that Fortran support is not enabled. > > Isn't that entirely dependent on the Fortran compiler? There is no > universal requirement that there be a relationship between Fortran > INTEGER and C int, for example. > > > Now taking a closer look at the op, I see nothing in the standard the > would > > require to provide the op if the corresponding language is not supported. > > While it could be nice (as a convenience for the users and also because > > there is no technical reason not to) to enable the loc op, on non native > > datatypes, this is not mandatory. Thus, the current behavior exposed by > > Open MPI is acceptable from the standard perspective. > > I believe the question is not whether it's standard-compliant to define > the types when they are not supported (the OP's usage doesn't sound > valid anyway because they are using the Fortran MPI datatypes to refer > to C types). Rather, the question is: if those types are > non-functional, can/should they be removed from the header. This, for > example, allows a configure script to test whether those datatypes > exist. > > Feature tests are far more reliable, accurate, and lower maintenance > than platform/version tests. When a package defines macros/symbols that > fail at run-time, it makes feature tests much more expensive. Even more > so when cross-compiling, where run-time tests require batch submission. > > The fact is that if a package makes it impractical to test features, the > end-user experience reflects poorly on that package and all of its > dependencies (though which user support passes). It's the sort of thing > that drives users and developers away from the platform. > > Since I don't think you can make the Fortran types reliable without > access to a Fortran compiler, my suggestion would be remove the symbols > when Fortran is not available. >
