Hello, On šeštadienis 08 Rugpjūtis 2009 22:52:22 Joey Hess wrote: > I need to be careful here. This change makes *all* packages that use > a make-based buildsystem start honoring DEB_BUILD_OPTIONS=parallel. > > But, turning on -j is known to break many crummy Makefiles. That's why > DEB_BUILD_OPTIONS=parallel is documented as something that should only > be enabled if the package's build system is known to support it. > > So, if we make this change, someone who currently always builds with > dpkg-buildpackage -j2 may suddently see packages failing to build, or > even misbuilding somehow. This seems very risky. > > Maybe instead dh needs to get a -j option; then if a rules file wants > to support DEB_BUILD_OPTIONS it could set the option. Or something along > those lines. However, would that really be any better than my earlier > suggestion for adding an override target?
We have a couple of issues here: 1) dpkg-buildpackage -jX sets both parallel=X AND MAKEFLAGS=-jX. Therefore, regardless if the package declares support for parallel=X or not, but uses $(MAKE) to build the package, it will build with -jX. Currently, dh "wall" prevents this behaviour, but it is possible to fix this in a clean way (without '+' hacks or overriding). But do we want to fix this? Btw, I'm proposing a clean implementation of your '+' hack here. Obviously, if only DEB_BUILD_OPTIONS has parallel=X without MAKEFLAGS set, parallel should not be automatically enabled. 2) Supporting overriding via parallel is non-optimal since parallel is an optional but official feature of Debian Policy. debhelper/dh should provide support for standardized things if possible (and it is possible). 3) The way to solve this is indeed dh -j/--parallel option to declare that the package supports parallel. What is more, some build systems (e.g. cmake) always generates parallel-safe Makefiles so it makes much sense to default to --parallel for them. However, the fact that makefile.pm is auto-detected at "build" step for cmake is not helping this case and unfortunately, I don't see another way how how to to solve this but some temporary file hacks (urgh!) or reordering of @BUILDSYSTEMS (moving cmake above makefile). So waiting for your answer. This bug IS a show stopper for huge source packages which could be built much faster on SMP systems (which are commodity these days). -- Modestas Vainius <modes...@vainius.eu>
signature.asc
Description: This is a digitally signed message part.
