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
