When you emerge an ebuild with distcc, it's a lottery for the user if the ebuild will build or not, as there are NO information about it can't be built with distcc. Reproducible: Always Steps to Reproduce: 1. FEATURES="distcc" MAKEOPTS="-j3" emerge xorg-x11 Actual Results: The ebuild files when it's trying to parallel compile code that can't be built in parallel (parts of the X11 is written like this) Expected Results: The ebuild should have a "flag" if it can be built in parallel or not, if not, build it normally after informed the user that the ebuild can't be built in parallel. This isn't a distcc bug and nor is it an ebuild bug either, it's a feature missing in the portage system.
This can be fixed by settings MAKEOPTS=1 in the ebuild, no?
I think 'emake -j1' is the suggestion.
I wonder if below is bad for QA: if has distcc $FEATURES; then einfo "You have \"distcc\" enabled" einfo "build with MAKEOPTS=-j1" emake -j1 || die "compile problem" else einfo "build with MAKEOPTS=$MAKEOPTS" emake || die "compile problem" fi It won't affect people have more than 1 CPU.
@ comment #3 : -j1 often gets set because packages don't build well in parallel, this has nothing todo with distcc itself, it merely exposes the problems : there are more users with a distcc setup than users with a multi-cpu setup. In general i think this bugreport is about adding a 'feature' that tells the user that something is being built 'jobs restricted'. I personally think it's a bit vain; sure in some cases it might have some impact if we build with -j12, but in most cases it just doesn't and as such it is not relevant to know if something is makejobs capped (while this is often for a good reason). My suggestion to the reporter : just grep the ebuild for '-j1' or MAKEOPTS if you really want to know & go with the defaults.
The suggestion of grepping don't work, take a look at xorg-x11. IMHO this suggestion is as good as removing the ACCEPT_KEYWORDS and tell the users to check the ebuilds ChangeLog to see if the ebuild is stable or not, or even builds on the CPU in question. It seems that no one is prepared to take on this subject properly, rather tell it's someone elses problem to fix. I would like to see something more like ACCEPT_KEYWORDS="ppc x86 -*" ACCEPT_DISTCC=1 or ACCEPT_KEYWORDS="ppc x86 -*" ACCEPT_DISTCC=0 And if the ACCEPT_DISTCC is set to 0, then FEATURES="distcc" would be ignored, and the ebuild would be completly buildt locally.
Do you have any examples where a package fails with distcc, but works with -jX locally? If not I dont see the point of adding a new env var when the information is already defined in the make call. Also what if an ebuild has multiple make calls and only one would fail with distcc?
agreed, like foser said, if something fails to build with distcc, chances are it's just a simple parallel build bug that only seems to be exposed with distcc if it fails in parallel with distcc, then you should (in theory) be able to reproduce it with good old -j and no distcc in other words, this bug should be punted and you should file bugs against packages which dont build in parallel
There are quite many packages that failes with distcc, but works fine locally (even with a high -j value), as a few example are gettext and zlib. I frankly see the only option to really have a varaible to allow/disallow distcc, or else see to drop distcc from the portage.
what version of zlib fails ? there was an issue with zlib not working properly (which distcc triggered), but that should be fixed (and thus distcc works now)
Invalidating this. File bugs against the pkgs that fail.
