On Tue, Jun 26, 2007, Bill Allombert wrote:
> I agree it is important that all debian/rules parse the options the same
> way. However "findstring" actually allow both spaces and commas as separator.
Sure, but $findstring(debug,nodebug) will match "debug" for example.
And it will also match build-debug, debug-deb, parallel-debug etc.
> > I find the recommendation of the Make function "findstring" a poor
> > one as it will match subwords and will make it harder to introduce new
> > keywords (as we will have to ensure the new keywords aren't matched in
> > current rules).
> Could you provide a Makefile snippet that implement your proposal
> instead of "findstring" ?
Yes, for example $(filter debug,$(DEB_BUILD_OPTIONS)) will return
"debug" if debug is listed as a separate word in DEB_BUILD_OPTIONS,
if DEB_BUILD_OPTIONS is a space separated list of words.
Peter Samuelson proposed a way to map DEB_BUILD_OPTIONS separated by
other separators into a space separated variable:
d_b_o:=$(shell echo "$$DEB_BUILD_OPTIONS"|sed 's/[^-_=[:alnum:]]/ /g'|tr
a-z- A-Z_)
There's also the sub-question of passing parameters with values (and
not only a boolean flag), such as parallel=n in DEB_BUILD_OPTIONS.
With a space-separated DEB_BUILD_OPTIONS, one can easily use:
DEB_BUILD_OPTIONS_PARALLEL ?= $(patsubst parallel=%,%,$(filter
parallel=%,$(DEB_BUILD_OPTIONS)))
Peter Samuelson proposed an eval snippet importing all
DEB_BUILD_OPTIONS vars into Make variables:
$(foreach o, $(d_b_o), $(if $(findstring =,$o),$(eval
DEB_BUILD_OPT_$o),$(eval DEB_BUILD_OPT_$o=1)))
(This works if you build d_b_o like proposed above or if you have a
space separated DEB_BUILD_OPTIONS.)
My preferred policy change would be to state that DEB_BUILD_OPTIONS
must be a space-separated list of keywords and parameters with
parameters taking the form "name=value". The allowed chars for name
and values would be limited to a-z, A-Z, 1-9, dash, and underscore.
--
Loïc Minier
