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

[Aurelien Jarno <aurelien@aurel32.net>]

Hi,

I have just noticed that that things are moving. Nice :)

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.

On Tue, Apr 10, 2007 at 03:19:56PM +0200, Loïc Minier wrote:
>  I added support for DEB_BUILD_OPTIONS_PARALLEL to some big packages
>  which are building multiple "flavors" of the software.  First, there's
>  a choice of what to parallelize: do you parallelize ./configure runs
>  and multiple builds when you have multiple configure + build runs to
>  achieve?  Second, I noticed that the output wasn't very easy to read,
>  especially with libtool based builds which produce several line of
>  output and run multiple commands per object.

On glibc we are running configure normally, and then invoking the build
phase with make -j. We still build all flavour sequentially. I can't say
what is the best solution. Building all the flavours sequentially has
the advantage to fail faster if some code does not compile. Not really
useful on the build daemon, but that can be useful locally.

>  So while I think it's a good thing to add such a support in packages
>  for some use cases (perhaps archive rebuilds, repetitive builds of the
>  same software after each commit etc.), I wonder how we will deal with
>  build logs.
> 
>  Should we recommend that such builds have to save their build logs and
>  output it at the end of the build?  e.g.:
>    make >>debian/build.log || (cat debian/build.log; exit 1)
>    cat debian/build.log
> 
>  This is what I used in my packages:
>     MAKEFLAGS += $(if $(DEB_BUILD_OPTIONS_PARALLEL),-j2 $(DEB_BUILD_OPTIONS_PARALLEL))
> 
>  (It wont work with packages calling $(MAKE) -f debian/rules which should
>  protect against adding another -j flag in the submake.)

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.

Bye,
Aurelien

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net