Hello, On ketvirtadienis 27 Rugpjūtis 2009 00:09:45 you wrote: > 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.
But maybe it is not such a bad idea after all? If you want to *safely* build in parallel mode, export DEB_BUILD_OPTIONS=parallel=X manually (dpkg- buildpackage messes with MAKEFLAGS if and only if -jX option is passed to it regardless of DEB_BUILD_OPTIONS contents). So dpkg-buildpackage does not violate policy. `dpkg-buildpackage -jX` != DEB_BUILD_OPTIONS=parallel=X, it is more. However, if you want to *try* to build in a parallel mode even if the package does not declare support for it (packaging might be out of date, maintainer might not care or something), you use `dpkg-buildpackage -jX`. There is a rather high probability the package may build. Policy does not talk about `dpkg-buildpackage -jX` while dpkg-buildpackage manual page clearly documents that it sets MAKEFLAGS only if -jX is passed to it. So I don't see why we should not try to support this use case. That's dh which puts a sort of artificial wall here. So should I include `dpkg-buildpackage -jX` detection in the patch or not? Either will be fine for me. > > 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. Do not forget that dh_auto_* makefile support has always (so far) relied upon dpkg-buildpackage to set CFLAGS/CXXFLAGS. When a package is built with plain `debian/rules binary`, it will frequently end up being compiled without any optimizations and/or -g option (unless upstream is clever enough to enable properly configured release builds by default). What is more, makefile.pm does not handle DEB_BUILD_OPTIONS="noopt" either. So another bug? > > 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? I meant debhelper should have support for parallel without requiring the use of override_dh_auto_build. Parallel is too important these days to require such non-obvious and tricky workarounds from maintainers... > > 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. Well, cmake has hooks to add custom targets and dependencies which may mess up its good support for parallelism. However, those are rather advanced stuff, not many people use. So basically yeah, it would be safe to enable --parallel for cmake. In those rare cases when it breaks, maintainers could disable it. However, since this is complicated to implement, let's ignore this part of the issue for now. It is far more important for dh_auto_* to get a manually specifiable --parallel option, imho. -- Modestas Vainius <[email protected]>
signature.asc
Description: This is a digitally signed message part.
