mpi

[Sean Farley]

Ryan Schmidt writes:

> On Sep 30, 2014, at 8:08 PM, Sean Farley wrote:
>> 
>> Ryan Schmidt writes:
>> 
>>> On Sep 30, 2014, at 7:04 PM, Sean Farley wrote:
>>> 
>>>> This is pretty much was is done (modulo the blacklist). If I understand
>>>> correctly, though, you want to remove gcc from being able to be used as
>>>> a compiler? This would be a serious limitation.
>>> 
>>> Removed as a C/C++/ObjC/ObjC++ compiler, yes. In what situations do you find that using gcc as the C/C++/ObjC/ObjC++ compiler is still necessary?
>> 
>> Of course there are many situations. We're talking about numerical code
>> here, so these projects are sometimes pushing the boundaries of what the
>> compilers can optimize. It is a great help if one can test both of these
>> cases out.
>> 
>> Flat out removing all gcc compilers is dead on arrival and will
>> ultimately drive people to ditch MacPorts.
>
> What also causes people to ditch MacPorts, or at least to file bug reports about it, is when ports like boost offer variants, which the user rightly assumes they can use, but whose use causes the port to either fail to compile or causes other ports using that port to fail to compile.
>
> Of course we'll keep the gcc ports in MacPorts, we just can't really offer the option of compiling arbitrary ports with g++ at the user's whim.
>
>
>> Using gcc for C and fortran, is not a problem. The only issue, of
>> course, is C++.
>
> True.
>
>> Even then, using C++ is only a problem when trying to
>> mix libc++ and libstdc++.
>
> Yup.
>
>> The question, to me, is: why is it still not
>> possible to distinguish foo+gcc and foo+clang in MacPorts?
>
> I'm not sure what you mean.

Why can't all a port's variants be installed at the same time?

$ port install boost
$ port install boost +gcc48

Every port could have its own custom prefix and only the active one
would be a symlink in /opt/local.

My point is that these issues all relate to depending on a port's
variant. This would be a powerful and very rich improvement to
MacPorts. A hacky alternative would be to provide a 'boost-stdlib' (or
whatever name) port that could be installed into a custom prefix for use
in this situation.