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