On Wed, Jun 01, 2016 at 09:57:20AM +0200, Matthieu Moy wrote: > Jeff King <peff@xxxxxxxx> writes: > > > Hmm. So I think this does fix some issues, but it also means that one's > > config.mak cannot use DEVELOPER as a base and then override particular > > flags. > > You mean, using "make DEVELOPER=1" and then tweak CFLAGS in config.mak? > > Well, you still can do "CFLAGS += ..." (the extra CFLAGS will come > before the ones added by DEVELOPER instead of after), which should cover > 99% use-cases. I specifically meant this, that your flags will now come before the DEVELOPER ones. So they will not override for any options which are parsed in command-line order (e.g., -Wno-error=something-specific). > You can't do "CFLAGS = $(filter-out ..., $(CFLAGS))" anymore indeed. But > if you are at that level of customization, I'd say DEVELOPER isn't for > you and you should just set CFLAGS directly. Yes, though it would be nice if the developer cflags were in a separate variable to make that easier to play with. Perhaps: DEVELOPER_CFLAGS += -Wfoo DEVELOPER_CFLAGS += -Wbar ... -include config.mak ... ifdef DEVELOPER CFLAGS += $(DEVELOPER_CFLAGS) endif would be more flexible. I don't currently use filter-out, but I do have compiler-specific flags (which I accomplish by just not adding them in the first place for certain compilers). For example, you may notice that: make DEVELOPER=1 CC=clang is broken (clang doesn't know -Wold-style-declaration). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html