mpi

[Ryan Schmidt]

On Sep 30, 2014, at 4:10 PM, Sean Farley wrote:

> -------
> Fortran
> -------
> 
> While the above matrix was relatively straight-forward to implement
> there was one glaring problem: fortran. LLVM / clang does not provide
> it. Wonderful.

What portion of ports that want mpi also need a fortran compiler? 95%? 5%?

> This creates the scenario of: does the port want the full suite of, for
> example, gcc (meaning both C and fortran) or just the fortran
> compiler.

And which of these two strategies does the mpi portgroup employ?

> This led to the creation of the 'require_fortran' monstrosity.

With the release of OS X 10.9 and its use of libc++ we seem to have found the use of gcc ports as values for configure.compiler untenable, giving rise to the fortran recipe which just sets the fortran compiler and leaves the C/C++/ObjC/ObjC++ compilers alone:

https://trac.macports.org/wiki/PortfileRecipes#fortran

I'm not sure if or how this relates to the require_fortran that you mentioned above.

> -------------
> Complications
> -------------
> 
> There are two complications with this implementation. The first is that
> there is no knowledge of configure.compiler (used for blacklisting).

I don't understand the situation in depth, but if mpi is requested, shouldn't we just inspect the value of configure.cc / configure.cxx / configure.obcj / configure.objcxx / configure.fc etc. (in a pre-configure block, to give a port time to change compiler.blacklist / compiler.whitelist / compiler.fallback), and replace them with their corresponding mpi wrappers? If a port needs a Fortran compiler then it would also need to provide gcc variants which would select only the fortran compiler, a la the fortran recipe.