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
