mpi

[Sean Farley]

Ryan Schmidt writes:

> 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.

They are the same problem as boost+mpi.

>> 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.

But it *does* change the graph when you do that. Which in turn makes it
difficult to reproduce stability.

> 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.

The solution to this problem is to better handle the dependency graph
(which is not easy).

>> 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.

That is one path, yes. Much easier than implementing what I'm talking
about. What I'm looking for is a definitive "this is when MacPorts
decided not to go that route," so I can link to it in the future.