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