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.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to