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/')
> >> + ifeq ($(DEB_BUILD_OPTIONS),$(PARALLEL_JOBS))
> >> + 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
> > parse DEB_BUILD_OPTIONS.
>
> > 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_PARALLELL=n, DEB_BUILD_OPTIONS_NOPT, and
> > 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.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: