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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev