Anyone opposed to me pushes the proposed changes and marking them fixed? Sean Farley writes:
> Ryan Schmidt writes: > >> 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). > > Not in this case. The mpi portgroup forces the same active compilers. > >> 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? > > Yes, the same must be used across the board. > >>> 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? > > As Eric pointed out, it's for experimenting. This is exactly the same as > the reason ATLAS uses different compilers: sometimes there is a speed > improvement. > >>> Perhaps you're missing that MPI is a library that provide compiler >>> *wrappers*? If a package needs MPI then that package is compiled with: >>> >>> CC=mpicc >>> CXX=mpicxx >>> FC=mpifort >>> etc. >> >> Sure, I'm missing that, and probably a lot of other things. For example: >> what is the goal? What does adding mpi support to boost do? Why would >> someone want this? > > So that a package could use Boost.MPI (such as dolfin does). > > MPI falls under the category of scientific computing. This changes a few > presumptions: the goal here is numerical computation (matrix vector > operations). > > Having one implementation just isn't feasible. Science users want to > experiment with each combination. You could say it's part of their > nature. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
