Dnia 2 grudnia 2015 11:00:20 CET, "Gregory M. Turner" <g...@be-evil.net>
napisał(a):
>On Wed, 2015-12-02 at 08:06 +0100, Michał Górny wrote:
>> On Tue, 01 Dec 2015 18:12:17 -0800
>> "Gregory M. Turner" <g...@be-evil.net> wrote:
>>
>> > On Tue, 2015-12-01 at 07:18 -0500, Anthony G. Basile wrote:
>> > > So on that bug we're talking about selectively
>> > > adding -std=c++11 (or possibly gnu++11) to packages.
>> >
>> > Yes, this is the biggest real-world problem we face. It requires
>> > an
>> > immediate solution in the ~* branches; the affected ebuilds just
>> > dump a
>> > bunch of gcc gobbldeygook and crash.
>> >
>> > If I understand the generalized problem we are facing there, as a
>> > package gets "c++11-ized", all of its reverse-BDEPs find themselves
>> > in
>> > the following situation:
>> >
>> > Imagine cat/foo is a library. cat/foo-3.0 is the newest non-c++11-
>> > ized
>> > version (in its slot, perhaps). Now cat/foo-3.1 comes along and
>> > from
>> > then on, anything BDEPENDing on it must be built with -std=c++11
>> > (I'm
>> > ignoring the c++11 vs. gnu++11 but presumably we'll eventually need
>> > to
>> > figure out some kind of game plan about that).
>>
>> Just to be clear, this only happened because upstream started to use
>> C++11 features in API. Normally libraries don't go that far, or use
>> #ifs to support C++03.
>>
>> > So, now, "everything" pulling in headers from cat/foo finds itself
>> > in
>> > this situation:
>> >
>> > o if it pulls in headers from <cat/foo-3.1, all is as before
>> > o if it pulls in headers from >=cat/foo-3.1, we must add a CFLAG
>> >
>> > I guess the reasonable way to achieve that sort of behavior is
>> > pkgconfig (which is not really a rock-solid solution. First, some
>> > packages might fail to put it in there (but, OK we just add it
>> > ourselves, let's say). Second, how many of cat/foo's reverse BDEPs
>> > side-step pkgconfig? Sometimes this is pretty common, I'm afraid.
>> >
>>
>> pkg-config is not a solution. -std= flags don't belong there.
>> Furthermore, if you put -std= flags there, it is likely to override
>> ${CXXFLAGS} and in particular make it really painful to force other
>> standard on ebuild's end.
>
>I see what you mean. Maybe pkgconfig needs a new feature? I wonder if
>they are already thinking about it in pkgconfig-land. I'll look around
>on their ml/bugdb and see if I can find anything.
Please don't. Pkg-config is already bad enough as it is, and they are known to
break stuff without any concern for compatibility.
>
>> > So, let's say lots of packages depending on cat/foo have this
>> > pkgconfig
>> > side-stepping problem, we could theoretically write some eclass to
>> > inject it when appropriate, and expect those side-stepping ebuilds
>> > to
>> > consume it, no? That seems pretty easy and hopefully wouldn't
>> > require
>> > any of the scary ideas that have been discussed in this thread.
>>
>> So you're saying we should write a whole eclass to do:
>>
>> append-cppflags -std=c++11
>>
>> ?
>
>If we could just do "append-cppflags" somewhere, it'd be a non-bug as
>we would have just done it. That doesn't seem to be the case.
>
>If I'm not mixed up, the difficulty is determining /when/ that's
>appropriate. Specifically, this c++11 requirement can bubble up
>indirectly through deep dependencies or even non-DEPENDencies. Source
>file "X" just needs to #include header "Y" that #include's header "Z"
>with the c++11 requirement, and "kablooey!".
>
>So, yeah, an eclass that figures out when to append the flag (and then,
>as you say, appends it) doesn't seem so crazy to me.
>
>For example: if we can identify the dependencies, deep, hidden, or not,
>that cause these failures (i.e., by waiting for bugzilla reports and
>acting on them), we could pretty trivially fix them with such an
>eclass.
>
>So, just imagining one possible implementation of that, here's a
>possible user-story -- which I mean, an eclass user (and therefore and
>ebuild or eclass developer, but developer-story isn't a word afaik):
>
>Bug wranglers observe that www-client/frobzilla ebuilds are crashing
>due to headers, which are coming, ultimately, from net-libs/tldr.
>
>Assignees of the bug would:
>
>o figure out which versions of net-libs/tldr trigger the problem
> and ensure they are selected by the hand-crafted list of
> DEPENDency specifiers that live in cxx11reqs.eclass.
>
>o add the following code to all affected www-client/frobzilla ebuilds:
>
> CXX11REQ_CULPRITS=( net-libs/tldr )
> inherit cxx11reqs
>
>This would cause the right thing to happen (CXXFLAGS augmentation) when
>and only when the affected versions of tldr are installed.
>
>Only thing left to do is to check that frobzilla doesn't strip the flag
>back out, for some reason; if it did, perhaps it could add it back in,
>by calling a xxx11reqs eclass API.
>
>Note that frobzilla might not even DEPEND on tldr (not even indirectly
>through several layers of DEPENDency); this would still do the trick;
>the eclass could just use has_version to find out if the flag is
>needed, according to a hand-crafted dependency specifier table.
>
>I guess as far as bright ideas go, that's the best I've got, for now.
>
>If a fully automagical solution is practical to implement, I haven't
>yet imagined it.
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.
>
>-gmt
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
