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