mpi

[Ryan Schmidt]

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.

For example, the php56-mysql port offers variants for selecting which mysql library to use to communicate with a mysql server. Ports that depend on php56-mysql don't care which of those variants is used, and it only makes sense to use one of them at a time. So it is perfectly reasonable that the user can only install one instance of the port.

It is, however, conceivable that the user may wish to install the php mysql module for more than one version of php simultaneously, and this is accomplished through subports: php53-mysql, php54-mysql, php55-mysql, php56-mysql.