Bug#209008: How should the build logs be handled?

[Loïc Minier <lool@dooz.org>]

On Wed, Apr 18, 2007, Aurelien Jarno wrote:
> First of all, I am personally in favor of DEB_BUILD_OPTIONS="parallel=n"
> because it is consistent with all other options that can be set when
> building a package. If the code to parse it is too long, it could be put
> for example in debhelper.

 This is a compatibility line to convert parallel=n in DEB_BUILD_OPTIONS
 into DEB_BUILD_OPTIONS_PARALLEL (unless DEB_BUILD_OPTIONS_PARALLEL is
 already set):

 DEB_BUILD_OPTIONS_PARALLEL ?= $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))

 You can then use DEB_BUILD_OPTIONS_PARALLEL as follows:
 MAKEFLAGS += $(if $(DEB_BUILD_OPTIONS_PARALLEL),-j$(DEB_BUILD_OPTIONS_PARALLEL))

 Or obviously any other flags if you prefer not changing the -j flags for
 debian/rules itself or for all sub-make invocations, as you describe
 below.

> I should warn about using MAKEFLAGS. A lot of software do support using 
> -j for the make all phase, but do not for the make install phase. In the
> case of the glibc, using -j for the make install phase was causing a
> build failure, rarely but enough often to bother us (and the SRM team).
> That's why I would advise to call make -j explicitely in the parts that
> have been well tested.

 (Ack, but it's a general problem not limited to make install: the same
 could be said about the main build process which might not be safe for
 make -j, or the testsuite, or debian/rules itself.)

-- 
Loïc Minier