Bug#430649: Please clarify splitting/syntax of DEB_BUILD_OPTIONS

[Loïc Minier <lool@dooz.org>]

        Hi,

On Wed, Jul 04, 2007, Russ Allbery wrote:
> 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.

 A couple of updates:
 - parsing a comma-separated list wouldn't require sed as shown in
   #209008 with this Make snippet to convert comma-separated to
   space-separated:
    , := ,
    DEB_BUILD_OPTIONS := $(subst $(,), ,$(DEB_BUILD_OPTIONS))
 - separating with commas prevents passing options with commas; a sample
   use case which might be useful in the near future could be passing
   CFLAGS/LDFLAGS via DEB_BUILD_OPTIONS, and some of these flags require
   commas to reach the linker/assembler/preprocessor (e.g. "-Wl,-O1")

 Note: there's an interesting issue in that CFLAGS or LDFLAGS are
 typically space separated and hence we would need to define how to pass
 multiple such flags in DEB_BUILD_OPTIONS...


 It seems to me that the more separators we allow, the less room for
 future expansion of DEB_BUILD_OPTIONS we keep and the more complex the
 early parsing of DEB_BUILD_OPTIONS will be.



 Additionally to the request to document the syntax and remove the
 recommendation for "findstring", I also wish Policy would document how
 to deal with a keyword being present multiple times.  For example:
    DEB_BUILD_OPTIONS="noopt parallel=2 debug parallel=1"

 On this particular subject, I would recommend that Policy requires to
 parse DEB_BUILD_OPTIONS from left to right and to override any previous
 parameter when its met a second time (latest definition wins).
   Perhaps it makes sense to explicitely mention "=" in parameters and
 the allowed chars in parameter names; I could imagine we could at some
 point support "+=":
    DEB_BUILD_OPTIONS="CFLAGS=-Os parallel=2 debug CFLAGS+=-g"
 (The += words could be parsed in Make using eval for example.)

-- 
Loïc Minier