Bug#430649: Please clarify splitting/syntax of DEB_BUILD_OPTIONS
Loïc Minier <lool@dooz.org> writes:
> 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.
At first glance, using a space-separated list of options would be a lot
easier to parse since you could parse it entirely with internal make
functions and not have to shell out to run sed. Plus, using whitespace as
a separator is much more natural for makefiles, and Policy now requires
that debian/rules be a makefile. That to me argues for making it
space-separated, but I'm not sure if that additional tightness in the
specification would cause problems for existing usage.
If everything is using the current Policy definition and just searching
for the substring, we can tighten without breaking any of the parsers, but
we might break what people are doing to set the value.
If someone could come up with a snippet that's better than:
OPTIONS := $(shell echo "$$DEB_BUILD_OPTIONS"|sed 's/[^-_=[:alnum:]]/ /g')
in terms of both complexity and how much shell code it runs, that would
make me more comfortable with the idea of supporting more arbitrary
delimiters. It doesn't look like there's a make equivalent to that sed
command, though.
I suppose one alternative is to use:
OPTIONS := $(shell echo "$$DEB_BUILD_OPTIONS" | sed 's/,/ /g')
which is simpler, although still a shell invocation, and would support the
two cases that people have specifically mentioned. We could then write
Policy language saying that either whitespace or commas are supported as
separators, and the example code would use $(filter ...) on $(OPTIONS).
(I'm not particularly worried about supporting case insensitivity; we
don't currently support that, which means that no one is expecting it.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: