Richard PALO <richard%netbsd.org@localhost> writes: > 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:[ See the big thread at https://mail-index.netbsd.org/tech-pkg/2015/09/25/msg015654.html >> 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. Yes, it may be. > Is it non trivial to mix libstdc++ and libc++, even with the same compiler? I am not sure. But overall there seems to be a notion that one has to choose a compiler/library and then stick with it. > I still feel there is need to be able to easily set -std= just like c99 does. That is perhaps a separable issue. > 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. Agreed; this is all in need of major revisions. > 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. Are you suggesting allowing gnu99 in USE_LANGUAGES, as a dialect? > Is there any palpable reason to disable extensions if the package > itself doesn't? Joerg's comment seems to go follow this reasoning. I could see wanting to disable them if the language with extensions isn't defined, but I'm not sure that's useful. >> 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. What I meant is if one uses gcc 4.8 for some and 5.1 for some, how is that going to work? And if we dont' mix versions, what does "requiring c++14" mean? > 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. I really don't understand what that means in practice in terms of compiler selection.
Attachment:
signature.asc
Description: PGP signature