| 1 |
On Mon, Nov 30, 2015 at 10:56 AM, Gregory M. Turner <gmt@×××××××.net> wrote: |
| 2 |
> I'm quoting myself from bug #566328 here. These were off-the-cuff |
| 3 |
> remarks that got away from me and became a call-to-arms... |
| 4 |
> |
| 5 |
> (In reply to Michał Górny from comment #7) |
| 6 |
>> This is never this simple. C++11 can change the ABI. So the point kinda is, |
| 7 |
>> we need to ensure that all C++ libraries in a depgraph use the same C++ |
| 8 |
>> version. |
| 9 |
> |
| 10 |
> This is pretty awful when you really think about it. I feel like I'm |
| 11 |
> watching a train-wreck in super slow motion. |
| 12 |
> |
| 13 |
> I'm not sure we're taking this seriously enough -- sooner or later it |
| 14 |
> seems destined to become a major clusterfuck if we don't do something |
| 15 |
> proactive about it now while the drawing-board is relatively |
| 16 |
> uncluttered. |
| 17 |
> |
| 18 |
> The only thing I can think of that has this kind of two-way depgraph |
| 19 |
> magic property are the major "abi" USE_EXPAND values (multilib-build |
| 20 |
> and python-r1, in other words). |
| 21 |
> |
| 22 |
> But those rely on fancy framework-generated USE-flag deps, which seem |
| 23 |
> like overkill and likely to incur unjustifiable user-experience-costs. |
| 24 |
> |
| 25 |
> Perhaps a solution to this cxx11 clusterfuck can be found that works |
| 26 |
> more like perl? By that I mean, pick your poison (respectively, your |
| 27 |
> cxx11 ABI of preference or your major perl version of choice), rely on |
| 28 |
> inbuilt portage features do the trick most of the time, and, when it |
| 29 |
> breaks, run "magically-fix-everything.sh," grab a caffeinated beverage |
| 30 |
> or three and fire up your favorite VOD client while the mess gets |
| 31 |
> magically cleaned up by robots somehow. |
| 32 |
|
| 33 |
I'm not sure I fully understand the problem, but what about |
| 34 |
a. Always define the c++11 flag |
| 35 |
b. Not support a system with mixed (and incompatible) c++ standards |
| 36 |
|
| 37 |
I personally don't think it seems reasonable to try to carry both |
| 38 |
c++03 and c++11 at the same time. This especially seems like nonsense |
| 39 |
to me in the gentoo world. gcc has or will soon switch to c++11 by |
| 40 |
default. Packages which can't be built will start having issues |
| 41 |
anyway. |
Archives