tech-pkg archive

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

Re: Add c++11 to USE_LANGUAGES

Joerg Sonnenberger <> 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

Home | Main Index | Thread Index | Old Index