mpi

[Sean Farley]

Ryan Schmidt writes:

> On Sep 30, 2014, at 10:48 PM, Sean Farley wrote:
>> 
>> Ryan Schmidt writes:
>> 
>>> On Sep 30, 2014, at 9:25 PM, Sean Farley wrote:
>>>> 
>>>>> That's not what variants are for. That's what subports are for.
>>>> 
>>>> Subports are trying to solve this but expose the implementation level
>>>> too far up. Only one solution should exist to depending on a
>>>> variant. Subports, unfortunately, put all the burden on the portfile
>>>> author and bloat the output of the list of ports.
>>>> 
>>>> $ port echo mpich*
>>>> mpich
>>>> mpich-clang
>>>> mpich-clang31
>>>> mpich-clang32
>>>> mpich-clang33
>>>> mpich-clang34
>>>> mpich-clang35
>>>> mpich-default
>>>> mpich-devel
>>>> mpich-devel-clang
>>>> mpich-devel-clang31
>>>> mpich-devel-clang32
>>>> mpich-devel-clang33
>>>> mpich-devel-clang34
>>>> mpich-devel-clang35
>>>> mpich-devel-default
>>>> mpich-devel-dragonegg31
>>>> mpich-devel-dragonegg32
>>>> mpich-devel-dragonegg33
>>>> mpich-devel-gcc43
>>>> mpich-devel-gcc44
>>>> mpich-devel-gcc45
>>>> mpich-devel-gcc46
>>>> mpich-devel-gcc47
>>>> mpich-devel-gcc48
>>>> mpich-devel-gcc49
>>>> mpich-devel-llvm
>>>> mpich-dragonegg31
>>>> mpich-dragonegg32
>>>> mpich-dragonegg33
>>>> mpich-gcc43
>>>> mpich-gcc44
>>>> mpich-gcc45
>>>> mpich-gcc46
>>>> mpich-gcc47
>>>> mpich-gcc48
>>>> mpich-gcc49
>>>> mpich-llvm
>>>> 
>>>> Why should this be exposed to the user? Imagine, now, if there were no
>>>> such thing as a variant. This would solve all the dependence issues on a
>>>> port's variant.
>>> 
>>> I'm trying to explain that this is not what variants were made for.
>>> 
>>> Variants are supposed to be for adding optional functionality, or choosing between options.
>> 
>> Variants create a new node in the dependency DAG. Subports create a new
>> node in the dependency DAG. There is no topological difference. The only
>> difference is in how they were implemented.
>
> As far as I understand, variants are not involved in the dependency DAG in MacPorts at this time. Only ports/subports are.

Variants *in MacPorts* are not involved in the DAG *due to
implementation*. They do indeed change the graph.

>> It is understandable to not want to implement the greater complexity.
>> Your proposal is to get rid of gcc for compiling C/C++. If that's the
>> direction MacPorts wants to go, then I'd request that it be uniform: no
>> port has any variant to change the C/C++ compilers.
>
> As I understand it, it is indeed our goal for ports not to have variants that change the C/C++ compilers. However, many ports have gcc variants from years ago before we fully understood the C++ standard library mismatch issues and they have not been updated. For each port that has compiler variants, we would need to examine them to see why they do that, and how to safely remove them.

The thorny ports (perhaps more) will be ATLAS and boost. A good place to
start would be to simplify the ports that use the compilers port group
and refactor that to make it use the configure.compiler logic. After
that, there are approximately 118 ports that use gcc as a compiler.