[Lucas Nussbaum]
> - the number of parallel jobs should be specified by the developer
> building the package. There's no way to automatically guess the
> value in a sensible way, since it doesn't depend only on the number
> of CPUs but also on the amount of RAM available.
Right.
> - there's a problem with the logs, since building in parallel could
> make it harder to read them. The common case would be to use make
> -j, which does a good job at keeping things readable. But when
> another solution is used (like OpenOffice.org's build of
> subprojects in parallel), the maintainer has to implement a
> solution to avoid mixing unrelated outputs.
This problem is worth mentioning, but ultimately I think it's a
maintainer decision. An out-of-order build log doesn't seem like an
important enough problem to spend too much maintainer time fixing.
When something FTB, it should generally be clear what failed, and if
not, you can always retry without parallel.
> - there is no consensus on the name of the option. Solutions are:
> + use parallel=n (where n is the number of jobs) in DEB_BUILD_OPTIONS
> + use a specific environment variable DEB_BUILD_OPTIONS_PARALLEL
>
> I personally prefer DEB_BUILD_OPTIONS="parallel=n".
+1. I currently support DEB_BUILD_OPTIONS=-j4 but I'd be happy to
change my rules file to support DEB_BUILD_OPTIONS=parallel=4. And I
don't like the idea of a proliferation of environment variables either.
> DEB_BUILD_OPTIONS_PARALLEL=n is easier to parse, but Loic Minier already
> gave us code to parse DEB_BUILD_OPTIONS=parallel=n:
> NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
This will only work if the options in DEB_BUILD_OPTIONS are
space-separated. I generally comma-separate mine, as you don't have to
quote that to a shell. This is something Policy should specify but
doesn't. Since Policy is ambiguous, might I suggest:
d_b_o:=$(shell echo "$$DEB_BUILD_OPTIONS"|sed 's/[^-_=[:alnum:]]/ /g'|tr a-z- A-Z_)
$(foreach o, $(d_b_o), $(if $(findstring =,$o),$(eval DEB_BUILD_OPT_$o),$(eval DEB_BUILD_OPT_$o=1)))
MAKE_-J += $(addprefix -j, $(DEB_BUILD_OPT_PARALLEL))
Then you use $(MAKE_-J) as a macro on specified $(MAKE) lines. Yes,
the above is 3 lines of complexity, but in return you get this:
ifndef DEB_BUILD_OPT_NOSTRIP
INSTALL_FLAGS += -s
endif
Compare to what Policy suggests:
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_FLAGS += -s
endif
Maybe it's just me, but in Policy's example, I always have to think for
a moment to figure out when the conditional is true and when it is
false. (And I have to cut and paste it from somewhere to get the
syntax right.) Whereas in my example it is immediately obvious.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Attachment:
signature.asc
Description: Digital signature