Bug#209008: New proposed wording for DEB_BUILD_OPTIONS

[Robert Millan <rmh@aybabtu.com>]

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 /.)