Hi! On Tue, 2016-11-01 at 18:05:08 +0000, Simon McVittie wrote: > Package: dpkg-dev > Version: 1.18.10 > Severity: wishlist
> I've just reported the FTBFS bug for a slang2 upload that failed on all > buildds due to a non-parallel-safe upstream build system. It appears that > all our official buildds build with DEB_BUILD_OPTIONS=parallel=n for n >= 2, > so any Architecture: any package that fails when built like that is de > facto RC-buggy already. > > It occurs to me that if dpkg-buildpackage defaulted to a parallel build > on hardware with multiple cores, then in practice maintainers would never > upload packages with this failure mode, because in practice maintainers > are using PCs with two or more cores. Also, test builds and final-upload > builds by maintainers who do not yet know about the -J option would go > faster, saving them time. > > Unlike -jauto, -Jauto respects "dh --no-parallel", making it relatively safe > to use everywhere - particularly since our buildds are already using > DEB_BUILD_OPTIONS=parallel=n anyway. Ah, nice suggestion. And the main issue that came to my mind when I read the Subject gets neutralized if the buildds are already doing this! I'm enabling this for 1.18.11. > The one difference that I would advocate in a default behaviour (and > perhaps for -Jauto itself) is that according to its documentation, > -Jauto falls back to an unlimited number of threads (make -j) if the > number of CPU cores cannot be determined. For memory-hungry compilations, > particularly C++, this causes everything to grind to a halt or even get > hit with the OOM killer. It seems to me that using some arbitrary number > of threads, perhaps the equivalent of -J2 or -J4, might be a better > fallback behaviour if the number of cores cannot be determined. Hmm perhaps this should be done indeed. Maybe even to 1. Although this should only happen on systems were neither «getconf _NPROCESSORS_ONLN» nor «getconf _NPROC_ONLN» return a value, which should not happen on most Unix systems. Thanks, Guillem
