Feedback on clang change (#53194)

[Marcus Calhoun-Lopez]

Yes, we are talking about the libstdc++ that is shipped with gcc6.
I should have made clear that a major downside of choice #2 is that it requires a library dependency on gcc6.
That is something that most (the vast majority of?) users will not want.
So perhaps choice #3 or choice #2  with the default variant only for systems prior to OS X Mavericks?

-Marcus

> On Jan 31, 2017, at 1:53 PM, Mojca Miklavec <mojca at macports.org> wrote:
> 
> On 31 January 2017 at 19:48, Marcus Calhoun-Lopez wrote:
>> 
>> There are three ways to allow clang to refer to MacPorts libstdc++.
>> 
>> 1) Create a *default* variant to have -stdlib=libstdc++ refer to MacPorts libstdc++.
>>    This was quite rightly rejected because clang should be “as compatible with the host as possible.”
>>    I only bring it up because the required patch is simpler.
>> 
>> 2) Create a new command switch -stdlib=macports-libstdc++ to refer to MacPorts libstdc++.
>> 
>> 3) Create a new subport clang-libstdcxx for which -stdlib=libstdc++ refers to MacPorts libstdc++.
> 
> Just to make sure: are we talking about libstdc++ 3 that is shipped with gcc6?
> 
> 
> While I'm currently not yet sure how or when to use this, I don't see
> a problem with #2.
> 
> Making it a non-default variant is probably useless, making
> "-stdlib=libstdc++" switch to libstdc++ from MP (option #1) is a
> no-go, creating a subport and having an additional compiler (option
> #3) sounds like an overkill.
> 
> Unless this introduces undesired side-effects (which I don't believe
> it does), I don't see the need for a variant. Unless the user does
> something special and makes the extra effort to use a non-startand
> flag -stdlib=macports-libstdc++, I guess that there won't be any
> side-effects anywhere. So I see no harm in making this the default
> once you do sufficient testing.
> 
> Mojca