mpi

[Ryan Schmidt]

On Oct 1, 2014, at 12:23 AM, Sean Farley wrote:

> Ryan Schmidt writes:
> 
>> On Sep 30, 2014, at 11:25 PM, Sean Farley wrote:
>>> 
>>> Ryan Schmidt writes:
>>> 
>>>> On Sep 30, 2014, at 10:48 PM, Sean Farley wrote:
>>>>> 
>>>>> 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.
>> 
>> I guess I'm not familiar with what graph you're talking about. I'm only concerned with how dependencies work in MacPorts, not some other real or hypothetical package manager.
> 
> I'm not talking about a package manager, just the dependency graph. What
> I'm trying to point out is that variants change the graph. For example,
> look at the wonky code of the dependents of cairo, checking for
> cairo+quartz vs. cairo+x11.

Agreed, quartz and x11 variants are another problem.


> It seems that you want to define variants as things that do not change
> the graph. If so, MacPorts would (and should) have to ensure that
> variant blocks don't change the dependencies (but then how to check the
> dependents of a port?).
> 
> You would have a simpler definition of a variant (something that enables
> an option but doesn't change the graph) but would end up with more
> (sub)ports.

A variant that adds a dependency on another port is not a problem. We do this all the time.

A variant that adds a dependency on a variant of another port is a problem, in that it's not possible, and the require_active_variants workaround is not ideal.


>>>>> 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.
>> 
>> Yes, atlas has a bunch of compiler variants. I would love for most or all of them to go away. But part of atlas needs fortran so it needs to deal with that at least.
> 
> I would love for fortran to go away, too, but certain packages will need
> different compilers.
> 
>> I already "fixed" boost by removing the use of the mpi portgroup. If mpi support needs to be brought back, then a general solution needs to be found for the mpi portgroup, which based on what you said earlier might be as simple as deferring its work until the pre-configure block.
> 
> MPI support is definitely needed. I did not say earlier that would
> work. I said that would only work if you and MacPorts decide to get rid
> of gcc C/C++ compilers (and unify compilers-group with
> configure.compilers).
> 
> I am a little worried that you glossed over the amount of work needed to
> make a general solution. There are two big choices:
> 
> 1) does the MacPorts community decide to tackle variants, subports,
>   graphs, etc.?
> 
> 2) does the MacPorts community drop support for gcc as a C/C++ compiler?
> 
> (2) is certainly less work but would also lose some advantage over other
> package managers.

The moment OS X 10.9 came around, we basically lost the ability to effectively use G++ (and even before then there were some issues). It's out of our control; we're at the mercy of the C++ library Apple uses, and the fact that G++ does not use it.