On 11/14/2014 06:58 AM, Michał Górny wrote: > Dnia 2014-11-14, o godz. 09:08:17 > Michael Orlitzky <[email protected]> napisał(a): > >> On 11/13/2014 10:17 AM, Ian Stakenvicius wrote: >> >>>> Isn't it possible to disable C++ in GCC with USE="-cxx"? >>> >>> It is.. but unfortunately there's no way in DEPEND to ensure it's >>> satisfied, as you can have a gcc installed with that flag enabled but >>> have a second one (that's actually selected in gcc-config) with it >>> disabled. A pkg_pretend check or a pkg_setup check (if you don't want >>> it to just fail in src_configure) is probably the best way to enforce >>> that one at this time. Unless there are other ways I'm not aware of?? >> >> Is this a case (as was recently suggested) where we're doing something >> stupid rather than asking for help from the PMS? This problem shows up >> in a few places -- off the top of my head: >> >> * GCC (see sys-apps/systemd-217.ebuild) >> * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild) >> * Python (all over the place) >> * Ruby (all over the place) >> >> Since all of the above are slotted, we can DEPEND on them, but we can't >> actually be sure that we're using the right slot at build time. The >> package manager knows that the right version is there, but it's not at >> the moment prepared to find and use it. >> >> Question 1: is it desirable to e.g. switch compilers, compile systemd, >> and then switch back? At first I thought the PM should respect my >> selected compiler, but after thinking about it for a few minutes, I've >> changed my mind. The compiler deps are just like anything else: if I ask >> portage to install systemd, it should do what it takes to install >> systemd assuming I approve the build plan. > > Relying on stuff that can be switched outside the PM scope is always > a bad idea. Think of eselect-opengl -- for a long time, people had to > switch the OpenGL implementation to xorg to build xorg server, and then > back to be able to use anything using OpenGL. Then we fixed xorg-server > to use the underlying headers directly.
Yeah, having ebuilds switch the global compiler configuration would be completely insane. If they need to select a different local compiler via a mechanism like CC and CXX, as you suggest below, then that's fine. > I think we should use the same solution for the gcc issues. We already > expect packages to respect CC & CXX -- why not set them then? I'm > keeping my CC & CXX at a specific gcc version for a long time now. > -- Thanks, Zac
