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