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

[Gregory M. Turner]

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

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.  

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.

-gmt