Modestas Vainius wrote: > Why in dh rather than dh_auto_*? > > 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.
> 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.
> 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)
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.
--
see shy jo
signature.asc
Description: Digital signature
