mpi

[Ryan Schmidt]

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.