Adding MPI back to Boost

[Eric A. Borisch]

On Sunday, December 14, 2014, Ryan Schmidt <ryandesign at macports.org> wrote:

>
> On Dec 14, 2014, at 12:21 PM, Sean Farley wrote:
> >
> > Ryan Schmidt writes:
> >
> >> So, this would add clang33, clang34, clang35 variants, for example? But
> these would be different from the clang 3.x provided by Xcode in some way?
> The MacPorts clang ports would be able to use MPI somehow, while Xcode
> clang would not?
> >
> > ... ?
>
> That's a bit how I feel about this mpi business, yes.
>
>
> > First of all, for the sake of completeness, the list of variants would
> > be:
> >
> > $ port info boost
> > boost @1.56.0_2 (devel)
> > Variants:             clang31, clang32, clang33, clang34, clang35,
> debug, mpich, mpich_devel, [+]no_single, [+]no_static, openmpi,
> openmpi_devel, python25, python26, [+]python27, python31, python32,
> python33, python34, regex_match_extra, universal
> >
> > The reason I wrote the mpi and compilers portgroup was because there was
> > no way to make sure the same compiler for both is selected. For example,
> >
> > $ port install boost +clang35 +mpich
> >
> > will install mpich (built with clang35 compilers) and boost (built with
> > clang35 compilers).
>
> Only if mpich had not already been installed with a different variant,
> since MacPorts does not have the capability to declare dependencies on
> variants (ticket #126).
>
> Is the correspondence of variants between e.g. boost and mpich required?
> In other words, if mpich is installed with +clang35, does that mean boost
> *must* use the +clang35 variant as well if one wants to use the +mpich
> variant, or would it work if +clang34 or clang from Xcode is used for boost?
>
>
> > The clang provided by Xcode can be used, of course, which is the
> > default:
> >
> > $ port install boost +mpich
> >
> > will install mpich (built with Xcode compilers) and boost (built with
> > Xcode compilers). This will change depending on the OS version.
>
> Under what circumstances would using Xcode clang not be sufficient? In
> other words, why would we ever want MacPorts clang variants?
>

Because people using mpich are typically interested in how their code
compiles under multiple different compilers, because they are
often targeting systems other than their mac with the software.

And the different compiler wrapping versions are not variants of mpich, but
are sub-ports that can be installed side by side and explicitly depended
upon.

   - Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20141214/04cacf53/attachment.html>