On Wed, Jul 04, 2007, Peter Samuelson wrote: > $(filter) filters on whitespace, so this still will not work for > "x=1,parallel=2". My code, posted earlier, handles the (perhaps > common) case of comma-separated DEB_BUILD_OPTIONS.
(It is because $(filter ) filters on whitespace that I fixed usage of findstring for consistency as the initial version mixed $(findstring ) and $(filter ); I ignored comma support on purpose as the initial version didn't support it.) I personally don't care that much about comma support for parallel=n; I don't think a lot of people use commas, but the policy syntax will be debated in its own bug, so I see no need to impose my view or your in this bug. [I found the comma-aware snippet heavier, but I'll implement it if support for commas gets more support (or becomes policy).] > Also, suggesting that one add this directly to MAKEFLAGS is probably > not great, as a lot of upstream Makefiles may not be -j-safe > everywhere. This is true of one package I maintain, so I construct a > $(MAKE_-J) and pass it manually to the $(MAKE) targets that are > -j-safe, and not to the ones that aren't. It's a good point to make, perhaps MAKEFLAGS should only be mentionned as a possibility instead of mentionning it in the make snippet. BTW, MAKEFLAGS also affects the make run for debian/rules, that is if you extend MAKEFLAGS, debian/rules must be -j-safe too. -- Loïc Minier