On Sun, Dec 30, 2007 at 07:23:58PM -0800, Russ Allbery wrote: > Okay, here's a revised proposal to address both Bug#209008 (parallel) and > Bug#430649 (DEB_BUILD_OPTIONS parsing). This proposal does the following: > > * Standardizes on space as the separator for DEB_BUILD_OPTIONS. This > only affects what people can pass into debian/rules, not any existing > packages. I think all existing packages use parsing methods that would > work with either, and that's what Policy has previously recommended. I > think the argument that we may want to pass values including commas to > an option is persuasive. > > * Adds parallel=n with wording tweaks based on subsequent discussion, > including handling the case where the build system supports some > concurrency but not as much as was requested. Do people still feel > that we need to explicitly say that, in the absence of this option, > packages should be built one process at a time? Note that supporting > DEB_BUILD_OPTS at all is only recommended. > > * Moves the whole section about DEB_BUILD_OPTS to a sub-section of the > section on debian/rules and out of the section on binaries, leaving a > pointer behind. There are flags that do things other than affect the > content of binaries, and I think this is a more intuitive place to look > for it. > > I left the MAKEFLAGS bit in the example for parallel since that example > clearly says that it's only an example and will need modification for the > needs of a specific package. The way INSTALL is handled in the example > that was already there similarliy won't work for all upstream build > systems. > > Comments? Seconds?
The majority of packages already supports parallel builds by simply passing the appropiate -j flag to make. Not that I object to a "parallel" parameter since it can bring some benefits in very specific situations, but please make sure this doesn't hinder what is already working. In particular: - It'd be good if it required that packages do not disable parallel flags in make in case they're already present (dpkg-buildpackage -jN), even if the parallel=N parameter is not present at all. - I think it'd make sense to add a "should" requirement that packages allow any amount of parallelisation. This requirement wouldn't really be excessive, I think. It's just a matter of writing Makefiles properly by defining the right targets and dependencies; something that's easily archieveable when people remove bad habits like assuming make processes dependencies in a particular order, etc. I can prepare a patch (based on yours) if you like. -- 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]
