Aurelien Jarno <[EMAIL PROTECTED]> writes: > On the other hand, DEB_BUILD_OPTIONS=parallel=n was ignored by packages > that have not been validated by the maintainers, and used by packages > that have been tested by the maintainer. Also it was possible to use > only on some parts of the build. For example the make install part is > sometimes problematic, and mainly depends on I/O throughput of the > machine, and not CPU. This make some problems difficult to detect, as > they happen only in rare case on some machines. > > Unfortunately dpkg-buildpackage now looks for DEB_BUILD_OPTIONS and call > debian/rules with -j and the value it founds in this environment > variable. That makes DEB_BUILD_OPTIONS=parallel=n useless, as it has the > same effect as dpkg-buildpackage -j. > > I personally think that supporting DEB_BUILD_OPTIONS=parallel=n on some > packages is a first goal to achieve. Supporting this option in the 100 > packages which take the longest to build would probably be a huge > improvement in build time of the whole archive, while being easier than > fixing all the packages in the archive.
I agree with this analysis. I think the MAKEFLAGS setting in dpkg-buildpackage should be removed and instead calling dpkg-buildpackage with the -j option should just set the parallel=n flag in DEB_BUILD_OPTIONS. From there, we can leave it to package maintainers to decide how to implement this. If someone *really* wants to try forcing make to do a parallel build, they can always set MAKEFLAGS themselves directly. The only drawback that I can see is that, without special intervention by the package, this doesn't run debian/rules itself in parallel. But I think the latter generates a lot of bugs and doesn't save a lot of time in practice, so I'm okay with that. > The most difficult part probably being changing the policy (sigh) as > some of them already support that, but through a specific environment > variable. My intention is to have parallel=n be specified in Policy 3.7.4. If you have a moment to review the wording in Bug#209008, feedback and seconds are certainly welcome. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
