Re: Parallel build results
Aurelien Jarno <email@example.com> 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
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 (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>