Hi Peff, On Thu, 8 Oct 2020, Jeff King wrote: > On Thu, Oct 08, 2020 at 12:06:47PM +0200, Johannes Schindelin wrote: > > > My little script also finds this: > > > > -- snip -- > > @@ -1231,8 +1231,8 @@ space := $(empty) $(empty) > > > > ifdef SANITIZE > > SANITIZERS := $(foreach flag,$(subst $(comma),$(space),$(SANITIZE)),$(flag)) > > -BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE) > > BASIC_CFLAGS += -fno-omit-frame-pointer > > +BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE) > > ifneq ($(filter undefined,$(SANITIZERS)),) > > BASIC_CFLAGS += -DSHA1DC_FORCE_ALIGNED_ACCESS > > endif > > -- snap -- > > > > I am not _so_ sure that we want to order `BASIC_CFLAGS`, but then, it does > > not hurt, does it? > > I agree it would not be wrong to reorder here from the compiler's > perspective, but: > > - the current ordering is not arbitrary; the intent was to show that > we are enabling -fsanitize, and then follow it up with any other > related options (first any that apply to all sanitizers, of which > there is only one, and then any sanitizer-specific ones). The patch > above splits that logic apart. > > - I'd worry that there are cases in which order _does_ matter to the > compiler. I'm not sure if anything that goes in CFLAGS might > qualify, but certainly order can matter for other parts of the > command-line (e.g., static library order). > > So it might be setting us up for confusion later. Fair enough. It's easy to exclude `.*_CFLAGS` via a negative look-behind: $key = ''; @to_sort = (); while (<>) { if ($#to_sort >= 0) { if (/^$key \+=/) { push @to_sort, $_; next; } print join('', sort @to_sort); @to_sort = (); } if (/^(\S+(?<!_CFLAGS)) \+=/) { $key = $1; push @to_sort, $_; } else { print $_; } } if ($#to_sort >= 0) { print join('', sort @to_sort); } Ciao, Dscho