[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#209008: debian-policy: [PROPOSAL] common interface for parallel building in DEB_BUILD_OPTIONS

On Sun, Sep 07, 2003 at 01:33:36PM -0500, Manoj Srivastava wrote:
> On Sat, 6 Sep 2003 19:12:50 -0400, Joey Hess <joeyh@debian.org> said: 
> > Robert Jordens wrote:
> >> +ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS)))
> >> + PARALLEL_JOBS := $(shell echo $(DEB_BUILD_OPTIONS) | \
> >> + sed -e 's/.*parallel=\([0-9]\+\).*/\1/')
> >> + PARALLEL_JOBS := $(shell if [ -f /proc/cpuinfo ]; \
> >> + then echo `cat /proc/cpuinfo | grep 'processor' | wc -l`; \
> >> + else echo 1; fi)
> >> + endif
> >> +endif +MAKEFLAGS += $(NJOBS)
> > That's a lot of boilerplate, almost enough to call for a program to
> > I don't understand why we have an environment variable with a
> > complex set of values in the first place. Surely something lile
> > DEB_BUILD_OPTIONS_NOSTRIP would not run us out of environment space,
> > and it's far easier to work with.
> 	One of the reasons was to not have to have policy amended for
>  every little variable that one came up with; the omnibus version
>  allows the list of things to be added to at will. Admittedly, this
>  makes for complex code; if the list gets too large

I don't see why policy would have to be amended for every little
variable any more than it currently does. We could easily just say that
variables named DEB_BUILD_OPTIONS_* may affect the build process, and
that the following are currently defined: etc. That'd be just the same
as the current situation as far as amending policy goes. We're claiming
a namespace, that's all.

We do have the problem that policy recommends, and virtually everyone
implements, the $(findstring) idiom, which means that we can never add a
DEB_BUILD_OPTIONS flag whose name has an existing flag as a substring.
While it may not actually be a problem with the current set of flags -
although I can easily imagine wanting to add something that contained
"debug", an old flag - I've always felt that this situation is
uncharacteristically technically suboptimal. Using separate environment
variable names would fix that problem, not that I particularly relish
the idea of trying to get it changed everywhere.

If we didn't want to change the existing flags, we could still reserve
DEB_BUILD_OPTIONS_* for extensions.


Colin Watson                                  [cjwatson@flatline.org.uk]

Reply to: