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.
> > 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.
-gmt
