I think you're overengineering. There are basicaly two use cases:
a- Developer building a package for a specific purpose (e.g. testing
an improvement), wanting to speed up this specific build.
b- Buildd admin wanting to speed up build of the overall archive [1].
(a) can be archieved simply by adding a flag to dpkg-buildpackage, such
that when used it will pass the corresponding -j flag to make when invoking
debian/rules (for consistency, it could also be -j) [2] [4].
(b) can't be archieved easily no matter what we do. If we make -j NCPUs
implicit, lots of packages will break. If we design an interface
such that each maintainer has to add cruft to her debian/rules to support
parallel builds, it will take ages anyway untill all maintainers add their
cruft.
OTOH, just by archieving (a) we automaticaly get developers to, in their own
interest, start using this feature and report (non-RC) bugs when it fails [5],
just because they want (like I do) to scratch their own itches. This will
gradualy improve parallel build support in a true bazaar fashion, untill we
reach a point in which we can declare it a release requirement [3], hence
obtaining (b).
[1] yes, this means build logs become ugly and unreadable, but people can still
rebuild if they need a sane log, just like they do for nostrip,noopt.
buildds could even do that when FTBFS is found. I think it's a reasonable
price to pay (specialy since the trend for multi-core CPUs is so
stablished now).
[2] true, this doesn't maximize the benefit for non-make packages, but:
- it does in the debian/rules part (which is very significant in multi-build
packages)
- the small proportion of non-make packages makes this benefit marginal
- *then* it might be useful to add the proposed cruft, at which point it
could co-exist with the make -j flag which is needed for debian/rules no
matter what.
[3] if a package is so braindamaged that parallel builds can't be supported,
there shouldn't be any problem with explicitly disabling/overriding -j in
$(MAKE) recursion (does MAKE+=-j1 suffice?)
[4] #355654 would also archieve that, although I think -j would be better.
[5] to us or to upstream; it doesn't necessarily mean more work in our side.
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
