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.
Attachment:
signature.asc
Description: PGP signature