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 | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
