tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: discussion seeked for c++ variants in USE_LANGUAGES



Le 09/11/15 14:38, Greg Troxel a écrit :
> 
> I object, at least for now, becuase this is inconsistent with the
> emerging consensus from the ongoing discussion.
> 
I guess I missed something, I can't find but two observations from
joerg and one from you not mentioning any of the below... sorry:[

> As I understand it, the biggest issue is that one cannot really use
> multiple C++ compilers on a given system at the same time.  Then, given
> that c++11 is now more or less normal, we should just let the c++ value
> imply c++11, and more or less consider any pre-c++11 C++ compiler to be
> defective.
> 
> So that more or less means that if the system gcc is 4.8 (4.7?) or
> newer, then we use it, otherwise we force 4.8, but via a variable that
> the user can set to pick a different value, intended to be set once,
> conceptually at bootsrap time.
> 
I believe this is even potentially worse now that you can [easily] switch c++ 
libraries with clang. 

Is it non trivial to mix libstdc++ and libc++, even with the same compiler? 

I still feel there is need to be able to easily set -std= just like c99 does.

Perhaps one of the real issues is that the patchset updates GCC_REQD
based upon these settings...

I remind I only added upon existing scripts... 

I'd be happy to yank updating GCC_REQD from the proposed patchset... 

Although judging from your comments, there seems to be quite a bit that perhaps needs to be revisted in compiler/gcc.mk... but that's beside the point here.

Also, just to get back to the patchset, since clang supports the -std=gnu*, perhaps both gcc and clang should use the -std=gnu* form.

Is there any palpable reason to disable extensions if the package itself doesn't?
Joerg's comment seems to go follow this reasoning.

> I don't follow how having c++11 and c++14 both is going to lead to
> working packages as a non-trivial number of packages need them and link
> with each other.
> 
I believe these have mostly to do with the features expected in the compiler.
ABI issues are *already* a subject since post c++98... no difference,really.

Having both c++11 and c++14 means that they are simply available to packages that
need them, not necessarily to enforce using them. That said, I have no 
personal need requiring it now, it was mainly for completeness.

(0b10)
-- 
Richard PALO



Home | Main Index | Thread Index | Old Index