Bug#209008: parallel building: DEB_BUILD_OPTIONS or DEB_BUILD_OPTIONS_PARALLEL

[Lucas Nussbaum <lucas@lucas-nussbaum.net>]

Hi,

I'm trying to summarize this bug:

- generally, everybody find the idea useful.

- the number of parallel jobs should be specified by the developer
  building the package. There's no way to automatically guess the value
  in a sensible way, since it doesn't depend only on the number of CPUs
  but also on the amount of RAM available.

- there's a problem with the logs, since building in parallel could make
  it harder to read them. The common case would be to use make -j, which
  does a good job at keeping things readable. But when another solution
  is used (like OpenOffice.org's build of subprojects in parallel), the
  maintainer has to implement a solution to avoid mixing unrelated
  outputs.

- there is no consensus on the name of the option. Solutions are:
  + use parallel=n (where n is the number of jobs) in DEB_BUILD_OPTIONS
  + use a specific environment variable DEB_BUILD_OPTIONS_PARALLEL

I personally prefer DEB_BUILD_OPTIONS="parallel=n".

DEB_BUILD_OPTIONS_PARALLEL=n is easier to parse, but Loic Minier already
gave us code to parse DEB_BUILD_OPTIONS=parallel=n:
NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))

Switching to several DEB_BUILD_OPTIONS_* options doesn't seem like a
good idea. It will require build tools to be modified to add all of
them, if we want to use them in cases where the environment is not
inherited (think of qemubuilder for example). The benefits are unclear,
and if DEB_BUILD_OPTIONS becomes too difficult to parse, this could
still be moved to debhelper.

Any arguments I missed?
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |