[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [RFC] C++ standard in ebuilds
From:       Dennis Schridde <devurandom () gmx ! net>
Date:       2018-09-21 7:17:17
Message-ID: 3911746.QXzu3d5OL2 () ernie
[Download RAW message or body]


On Tuesday, 18 September 2018 16:31:23 CEST Guilherme Amadio wrote:
> On Mon, Sep 17, 2018 at 10:24:48AM -0700, Matt Turner wrote:
> > I don't understand what a potential solution would be.
> > 
> > The various projects use -std=c++XXX because that's what their code
> > requires. -std=c++XXX can't generally be changed. If a dependent
> > project is incompatible that's no different than any other case of
> > incompatible dependencies in Gentoo.
> > 
> > I think -std=c++XXX discussions before happened because gcc changed
> > the C++ ABI with -std=c++11. I don't think that's particularly
> > relevant here, since as far as I know different -std=c++XXX values
> > don't change the ABI with current gcc.
> > 
> > So I guess my understanding is that there isn't a problem different
> > than existing incompatible dependencies, but maybe I have
> > misunderstood you.
> 
> My concern is with, say, package foo that depends on both bar and baz,
> and bar and baz support from C++11 to C++17, but must be compiled with
> the same version of the standard so that foo can link against both of
> them without having a broken ABI. I think that depending on bar[c++14],
> or having a similar mechanism to Python to handle "same version of the
> standard" with ${CXXSTD_REQUIRED_USE} or similar in an eclass would be
> nice.

Maybe add a CXXABI USE_EXPAND variable and then handle this case similar to 
python-single-r1.eclass packages with CXXABI_COMPAT and CXXABI_USEDEP?
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]