Joerg Sonnenberger <joerg%bec.de@localhost> writes: > On Fri, Apr 14, 2017 at 12:15:03PM +0200, Edgar Fuß wrote: >> > My impression is that each compiler version has its own private C++ ABI, >> > compared to C where there is a defined API and you can link code from >> > multiple compilers. >> If that is indeed the case, the only working scheme seems to be to wire down >> the supported C++ (compiler) version in a mk.conf variable, build that version >> as soon as anyone needs C++ (if it's not in base) and fail for any package >> requiring a higher verson, no? > > Effectively, yes. This is clearly not hard to implement. The only real question is how much it hurts, in which ways on which platforms, and what the default should be. I am offering the following to be constructive on the path to improvement, since we need to get concrete, but I do not hold any of these positions strongly: - Add c++11 and c++14 to USE_LANGUAGES. Have it add GCC_REQD of 48 and 49. Be ok with ++14 choosing 5 or 6 in not too long if we figure out that 4.9's C++14 support isn't good enough for most. - Figure out what to do about --std and be consistent. - For packages declaring c++11/c++14, remove GCC_REQD if it follows the standard rules. - On platforms with < 4.8 native, choose 6 as default. (Once you have to build, might as well be modern.) - On platforms with 4.8 native, choose 4.8. Accept some issues with c++14, at least for now. - On platforms with > 4.8 native, choose the native version. - In all cases, let the user override the choice of default. - Add logic to fail if GCC_REQD is > than the chosen version, at least if some c++ flavor is in USE_LANGUAGES. - Perhaps allow different compilers for plain C, perhaps not.
Description: PGP signature