Loïc Minier <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
