On Tue, 01 Dec 2015 18:12:17 -0800 "Gregory M. Turner" <[email protected]> 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.
> 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
?
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
pgpTm7Z5xOLUB.pgp
Description: OpenPGP digital signature
