Sveiki, On ketvirtadienis 29 Spalis 2009 22:36:32 Joey Hess wrote: > > 1) It is very likely that maintainers who use dh_auto_* directly in > > debian/rules (not via overrides) want more control over build process. So > > they are given it. > > You can set --parallel=1 at either level. The inconsistency of defaults > does not lead to more control. It does however, mean that adding: > > build: > dh_auto_build > > to a rules file suddenly, and unexpecedly, makes parallel builds stop > working when they would have worked before.
Well, yeah. > > 4) More complicated implementation is needed. If we clean makeflags in dh > > to suppress warnings, dh_auto_* will not be able to auto-detect > > dpkg-buildpackage -jX using "unavailable jobserver" method. > > Why does the -jX method need to be used? dpkg-buildpackage -j also sets > DEB_BUILD_OPTIONS. Policy defines parallel=n. n is NOT optional. `dpkg-buildpackage -j` sets some bogus value -1 (aka unlimited?) which is not supported by policy... Yeah, it seems that thing is really a bit broken. > > Actually, I disagree that packages using dh do not need to specify > > --parallel with this feature present. If the package actually *builds* in > > parallel, it still needs to specify --parallel and that's still a valid > > bug if it doesn't. > > I saw that you said that in the man page, but even with that warning I > would expect 9/10th of debhelper users to stop once dpkg-buildpackage -j > worked, and never explicitly add --parallel. > > > When (if) dpkg-buildpackage -jX stops > > messing with MAKEFLAGS, this dh hack will stop working but so will > > standard dh-make templates without any explicit parallel handling and > > most other packages (not sure about cdbs though)... > > Which is another reason to dislike the hack, since it will be another > reason for the dpkg developers to continue touching MAKEFLAGS. > > > Currently there seem to me to be two viable choices: > > 1. Require --parallel explicitly be used before looking at > DEB_BUILD_OPTIONS. This tries to avoid misbuilds of unparallelizable > packages by hoping that maintainers will test when they add it. It > doesn't really avoid all breakage, because > a) Some maintainers will cargo-cult it from a template w/o testing. > b) Nobody will test with every possible -j number. > c) When a build system has parallel support newly added to it, > the flag will start to take effect, and expose previously hidden > problems. > > (Implemented in parallel branch) > > 2. Always honor DEB_BUILD_OPTIONS unless --parallel=1 (or =2 etc) > overrides it. This maximises the set of packages that can be built > in parallel and assumes that guarding against misbuilds is not > something debhelper should worry about, while still allowing maintainers > who know of a problem with parallel builds to disable it. > > (Implemented in parallel-implicit branch) My vote surely goes for this. But since it seemed like you had already rejected this idea earlier [1], I resorted to some `dpkg-buildpackage -j` detection hacks :-) I fully support this idea including rename to --max- parallel. Consistency and clean interface is kept and parallel support is ON by default. However, I'm a bit concerned about the fact that there is no way to tell dh_auto_* (-> makefile.pm) not to pass -jX to make at all (i.e. defined $this- >get_parallel() in makefile.pm:do_make() will never be false). Some packages might need this. In parallel branch, this used to be the case when --parallel was not specified at all (hence set_parallel() never got called and $opt_parallel defaulted to undef). Now set_parallel() is always called and always defines $opt_parallel to some value. Maybe --max-parallel=-1 for this (since --max-parallel/--max-parallel=0 is already an alias for "unlimited")? 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532805#32 > > 3. Actually, honorable mention would be to move the data about > what build flags a package supports into the control file, as I > suggested in #489771. Then dpkg-buildpackage could avoid enabling > a parallel build mode if a package's control file indicated it did not > support it. Anyway, the implementation of this in debhelper is the > same as #2, except without needing the --parallel flag. Yeah, I hope, dpkg people work something out for Squeeze. I'm also concerned about #544844 since I do not export C(XX)FLAGS in debian/rules anywhere and rely on dpkg-buildpackage to do this. -- Modestas Vainius <modes...@vainius.eu>
signature.asc
Description: This is a digitally signed message part.
