1 |
On Wed, 2015-12-02 at 08:06 +0100, Michał Górny wrote: |
2 |
> On Tue, 01 Dec 2015 18:12:17 -0800 |
3 |
> "Gregory M. Turner" <gmt@×××××××.net> wrote: |
4 |
> |
5 |
> > On Tue, 2015-12-01 at 07:18 -0500, Anthony G. Basile wrote: |
6 |
> > > So on that bug we're talking about selectively |
7 |
> > > adding -std=c++11 (or possibly gnu++11) to packages. |
8 |
> > |
9 |
> > Yes, this is the biggest real-world problem we face. It requires |
10 |
> > an |
11 |
> > immediate solution in the ~* branches; the affected ebuilds just |
12 |
> > dump a |
13 |
> > bunch of gcc gobbldeygook and crash. |
14 |
> > |
15 |
> > If I understand the generalized problem we are facing there, as a |
16 |
> > package gets "c++11-ized", all of its reverse-BDEPs find themselves |
17 |
> > in |
18 |
> > the following situation: |
19 |
> > |
20 |
> > Imagine cat/foo is a library. cat/foo-3.0 is the newest non-c++11- |
21 |
> > ized |
22 |
> > version (in its slot, perhaps). Now cat/foo-3.1 comes along and |
23 |
> > from |
24 |
> > then on, anything BDEPENDing on it must be built with -std=c++11 |
25 |
> > (I'm |
26 |
> > ignoring the c++11 vs. gnu++11 but presumably we'll eventually need |
27 |
> > to |
28 |
> > figure out some kind of game plan about that). |
29 |
> |
30 |
> Just to be clear, this only happened because upstream started to use |
31 |
> C++11 features in API. Normally libraries don't go that far, or use |
32 |
> #ifs to support C++03. |
33 |
> |
34 |
> > So, now, "everything" pulling in headers from cat/foo finds itself |
35 |
> > in |
36 |
> > this situation: |
37 |
> > |
38 |
> > o if it pulls in headers from <cat/foo-3.1, all is as before |
39 |
> > o if it pulls in headers from >=cat/foo-3.1, we must add a CFLAG |
40 |
> > |
41 |
> > I guess the reasonable way to achieve that sort of behavior is |
42 |
> > pkgconfig (which is not really a rock-solid solution. First, some |
43 |
> > packages might fail to put it in there (but, OK we just add it |
44 |
> > ourselves, let's say). Second, how many of cat/foo's reverse BDEPs |
45 |
> > side-step pkgconfig? Sometimes this is pretty common, I'm afraid. |
46 |
> > |
47 |
> |
48 |
> pkg-config is not a solution. -std= flags don't belong there. |
49 |
> Furthermore, if you put -std= flags there, it is likely to override |
50 |
> ${CXXFLAGS} and in particular make it really painful to force other |
51 |
> standard on ebuild's end. |
52 |
|
53 |
I see what you mean. Maybe pkgconfig needs a new feature? I wonder if |
54 |
they are already thinking about it in pkgconfig-land. I'll look around |
55 |
on their ml/bugdb and see if I can find anything. |
56 |
|
57 |
> > So, let's say lots of packages depending on cat/foo have this |
58 |
> > pkgconfig |
59 |
> > side-stepping problem, we could theoretically write some eclass to |
60 |
> > inject it when appropriate, and expect those side-stepping ebuilds |
61 |
> > to |
62 |
> > consume it, no? That seems pretty easy and hopefully wouldn't |
63 |
> > require |
64 |
> > any of the scary ideas that have been discussed in this thread. |
65 |
> |
66 |
> So you're saying we should write a whole eclass to do: |
67 |
> |
68 |
> append-cppflags -std=c++11 |
69 |
> |
70 |
> ? |
71 |
|
72 |
If we could just do "append-cppflags" somewhere, it'd be a non-bug as |
73 |
we would have just done it. That doesn't seem to be the case. |
74 |
|
75 |
If I'm not mixed up, the difficulty is determining /when/ that's |
76 |
appropriate. Specifically, this c++11 requirement can bubble up |
77 |
indirectly through deep dependencies or even non-DEPENDencies. Source |
78 |
file "X" just needs to #include header "Y" that #include's header "Z" |
79 |
with the c++11 requirement, and "kablooey!". |
80 |
|
81 |
So, yeah, an eclass that figures out when to append the flag (and then, |
82 |
as you say, appends it) doesn't seem so crazy to me. |
83 |
|
84 |
For example: if we can identify the dependencies, deep, hidden, or not, |
85 |
that cause these failures (i.e., by waiting for bugzilla reports and |
86 |
acting on them), we could pretty trivially fix them with such an |
87 |
eclass. |
88 |
|
89 |
So, just imagining one possible implementation of that, here's a |
90 |
possible user-story -- which I mean, an eclass user (and therefore and |
91 |
ebuild or eclass developer, but developer-story isn't a word afaik): |
92 |
|
93 |
Bug wranglers observe that www-client/frobzilla ebuilds are crashing |
94 |
due to headers, which are coming, ultimately, from net-libs/tldr. |
95 |
|
96 |
Assignees of the bug would: |
97 |
|
98 |
o figure out which versions of net-libs/tldr trigger the problem |
99 |
and ensure they are selected by the hand-crafted list of |
100 |
DEPENDency specifiers that live in cxx11reqs.eclass. |
101 |
|
102 |
o add the following code to all affected www-client/frobzilla ebuilds: |
103 |
|
104 |
CXX11REQ_CULPRITS=( net-libs/tldr ) |
105 |
inherit cxx11reqs |
106 |
|
107 |
This would cause the right thing to happen (CXXFLAGS augmentation) when |
108 |
and only when the affected versions of tldr are installed. |
109 |
|
110 |
Only thing left to do is to check that frobzilla doesn't strip the flag |
111 |
back out, for some reason; if it did, perhaps it could add it back in, |
112 |
by calling a xxx11reqs eclass API. |
113 |
|
114 |
Note that frobzilla might not even DEPEND on tldr (not even indirectly |
115 |
through several layers of DEPENDency); this would still do the trick; |
116 |
the eclass could just use has_version to find out if the flag is |
117 |
needed, according to a hand-crafted dependency specifier table. |
118 |
|
119 |
I guess as far as bright ideas go, that's the best I've got, for now. |
120 |
|
121 |
If a fully automagical solution is practical to implement, I haven't |
122 |
yet imagined it. |
123 |
|
124 |
-gmt |