Modestas Vainius wrote: > 1) dpkg-buildpackage -jX sets both parallel=X AND MAKEFLAGS=-jX.
My opnion of dpkg-buildpackage's recent spate of interfering with the build environment just went down another notch. They seem not to grok the intent of DPKG_BUILD_OPTIONS=parallel, which is to allow the package maintainer to *decide* if parallel builds are supported. > Obviously, if only DEB_BUILD_OPTIONS has parallel=X without MAKEFLAGS set, > parallel should not be automatically enabled. Not obvious to me. Policy only talks about DEB_BUILD_OPTIONS=parallel, not MAKEFLAGS. MAKEFLAGS may have nothing to do with the actual build system. Packages may be built without use of dpkg-buildpackage. > 2) Supporting overriding via parallel is non-optimal since parallel is an > optional but official feature of Debian Policy. debhelper/dh should provide > support for standardized things if possible (and it is possible). Not sure what you're saying here. Supporting *what* overriding parallel is non-optimal? > 3) The way to solve this is indeed dh -j/--parallel option to declare that > the > package supports parallel. What is more, some build systems (e.g. cmake) > always generates parallel-safe Makefiles so it makes much sense to default to > --parallel for them. However, the fact that makefile.pm is auto-detected at > "build" step for cmake is not helping this case and unfortunately, I don't > see > another way how how to to solve this but some temporary file hacks (urgh!) or > reordering of @BUILDSYSTEMS (moving cmake above makefile). Are you really sure cmake always supports parallel builds? It's easy to take an innocuous feature, like the ability to run an arbitrary command during the build, and use that to make a makefile that breaks parallelism. Not being familiar with cmake, I don't know if it has such a feature, but that would be a significant feature to leave out. -- see shy jo
signature.asc
Description: Digital signature
