Re: [gentoo-dev] impending c++11 clusterfuck?

[Michał Górny]

On Tue, 01 Dec 2015 18:12:17 -0800
"Gregory M. Turner" <gmt@×××××××.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.

> 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/>