Dave Love <d.l...@liverpool.ac.uk> writes: > Jed Brown <j...@jedbrown.org> writes: > >> 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. > > In case it's not generally obvious: the compiler _and its options_. > You can typically change the width of real and double precision, as with > gfortran -default-real-8, and similarly for integer. (It seems unKIND > if the MPI standard specifically enshrines double precision, but > anyhow...)
Indeed. (Though such options are an abomination.) >> 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. > > Right, but isn't the existence of the compiler wrapper the appropriate > test for Fortran support, and don't you really need it to run > Fortran-related feature tests? The wrapper might not exist. It doesn't on many prominent platforms today. > I have an "integer*8" build of OMPI, for instance. It's a pain > generally when build systems for MPI stuff avoid compiler wrappers, > and I'd hope that using them could make possibly-unfortunate standards > requirements like this moot. Would there be a problem with that in > this case? In the example of my other reply, my library would not need to call MPI From Fortran, but needs to know whether it needs to compile support for decoding Fortran datatypes. My personal opinion is that compiler wrappers are gross (they don't compose), but systems like CMake that insist on circumventing compiler wrappers in a yet more error-prone way are worse.
signature.asc
Description: PGP signature
