mpi

[Sean Farley]

Ryan Schmidt writes:

> We've had multiple bug reports from users who had installed boost with one of the gcc variants. Either the build failed when using those variants, or the build of boost succeeded but then the build of another port that depends on boost failed. We attributed this to the mixing of C++ runtimes on 10.9+. I removed the compiler variants from the boost port, but this has the effect of making it impossible to install boost with mpi support, which apparently some ports like dolphin require.
>
> I have to say I have no understanding of what mpi is or what the mpi portgroup is doing. Sean, could you explain?

------------
Introduction
------------

MPI is a way to do parallel programming and stands for 'message passing
interface.' There are two major implementations: OpenMPI and
MPICH. Simply put, they are just libraries. A (IMHO, bad) decision was
made long ago to provide a compiler wrapper that would link the MPI
libraries so that a user could type:

mpicc test.c

----------
First step
----------

This made the first step of trying to build MPI ports in MacPorts
apparent: provide a way to supply the MPI compiler wrapper to a port.

That means providing a way to obtain values from the matrix of compilers
and MPI libraries: (fixed width font below)

         clang  clang  ...   gcc   gcc   ...   gcc   ...  dragonegg  ...
          3.1    3.2         4.4   4.5         4.9           3.1
        +------+-----+-----+-----+-----+-----+-----+-----+---------+-----+
MPICH   |      |     |     |     |     |     |     |     |         |     |
        +------+-----+-----+-----+-----+-----+-----+-----+---------+-----+
OpenMPI |      |     |     |     |     |     |     |     |         |     |
        +------+-----+-----+-----+-----+-----+-----+-----+---------+-----+

-------
Fortran
-------

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

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. This led to the creation of the 'require_fortran' monstrosity.

-------------
Complications
-------------

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

The second, more difficult, complication is that this implementation
uses variants meaning only one version can be active at a time. This is
the very core of issue 126: https://trac.macports.org/ticket/126

Some package managers treat variants as subports. This would mean
installing each version / variant of a port into its own unique
path. For example,

foo-1.0: /opt/local/foo-1.0
foo-1.0+variantA: /opt/local/foo-1.0+variantA
foo-1.1+variantB: /opt/local/foo-1.1+variantB

For the convenience of building software outside the MacPorts tree, you
could set the active version of a port by symlinking its files into
/opt/local.

Changing MacPorts to this model would be no easy task.

Hopefully, now we can see the reason for the original problem: variant
dependence. If a user wants dolfin with gcc49:

$ port install dolfin +mpich +gcc49

Then this installs boost with +mpich +gcc49, forcing everything linking
to this version of boost to be compiled (and linked) with gcc's C++
compiler.