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
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
