On 05.02.2026 09:44, Bertrand Marquis wrote: > Hi Jan, > >> On 5 Feb 2026, at 09:23, Jan Beulich <[email protected]> wrote: >> >> On 05.02.2026 08:44, Bertrand Marquis wrote: >>>> On 4 Feb 2026, at 17:15, Jan Beulich <[email protected]> wrote: >>>> On 04.02.2026 16:45, Bertrand Marquis wrote: >>>>>> On 4 Feb 2026, at 16:31, Jan Beulich <[email protected]> wrote: >>>>>> On 04.02.2026 14:16, Bertrand Marquis wrote: >>>>>>> Xen does not currently document how to build the hypervisor on macOS, >>>>>>> and >>>>>>> there is no Darwin configuration for a Homebrew-based toolchain. In >>>>>>> addition, the Makefile silent-mode detection can be tripped by -I paths >>>>>>> that contain an "s", which hides build commands unexpectedly. >>>>>> >>>>>> This wants submitting as a standalone fix, so it can be backported. But >>>>>> see >>>>>> also below. I don't, however, understand how -I could be useful here - >>>>>> our >>>>>> build system is self-contained, so any include directives used should be >>>>>> satisfiable without any -I. >>>>> >>>>> This is added automatically inside our Makefile if you build out of tree: >>>>> >>>>> MAKEFLAGS += --include-dir=$(abs_srctree) >>>>> >>>>> which ends up being -Ixxx when tested. >>>> >>>> Hmm, but I do have an 's' in my source path, yet I need to explicitly pass >>>> -s for the build to be silent. >>> >>> I did further investigations and my previous assumptions where actually >>> wrong because i looked tat MAKEFLAGS value once the whole Makefile >>> was parsed and the include-dir flag is added after so it was not the reason >>> of the issue. >>> >>> In fact the issue is coming from variables set on the command line (and >>> in my case O= with a path containing a s). >>> So you can easily reproduce the issue by just passing XX=s to the make >>> command line to do a test. >>> >>> As a consequence, your proposed solution filtering -% is not working and >>> the only reliable solution is to actually use firstword to actually get the >>> short options list. This is making an assumption on MAKEFLAGS having >>> them first but my tests are showing that it is always the case. >>> I would propose to put a comment to explain the assumptions on which >>> the filtering is based on top: >>> >>> Something like this: >>> diff --git a/xen/Makefile b/xen/Makefile >>> index 13e336ba5484..a7924fcb7af5 100644 >>> --- a/xen/Makefile >>> +++ b/xen/Makefile >>> @@ -113,10 +113,10 @@ else >>> Q := @ >>> endif >>> >>> -# If the user is running make -s (silent mode), suppress echoing of >>> -# commands >>> - >>> -ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),) >>> +# If the user is running make -s (silent mode), suppress echoing of >>> commands. >>> +# This relies on GNU make encoding short options in the first MAKEFLAGS >>> word; >>> +# if this changes in the future, this check may need revisiting. >>> +ifneq ($(findstring s,$(firstword $(MAKEFLAGS))),) >>> quiet := silent_ >>> endif >>> >>> Also i can put a fixes tag if you think that is useful: >>> Fixes: 4fdb4b71b152 ("xen/build: introduce if_changed and if_changed_rule") >>> >>> Please tell me if that sounds ok for you and I will resubmit this as 2 >>> different patches >>> instead of a single one. >> >> Sadly no, see my other reply sent earlier today. Furthermore, as said there, >> even > > Sorry missed you reply when i wrote mine. > >> with O= I can't repro what you say. In fact with a Makefile containing just > > interesting > >> >> $(warning MAKEFLAGS="$(MAKEFLAGS)" ABC="$(ABC)" XYZ="$(XYZ)") >> >> all: >> @echo 'MFLAGS=$(MFLAGS)' >> @echo 'MAKEFLAGS=$(MAKEFLAGS)' >> >> I can observe (with both make 4.0 and make 4.2.1) $(MAKEFLAGS) expanding >> differently depending on where it's used (I'm passing ABC= and/or XYZ= to >> experiment): Only the use in the rule has the variables. What version of >> make are >> you using? > > I am using make 4.4.1 on both my Linux and brew based builds which might > explain > why i always see the same. > > I have an other linux system where i have make 4.3 and in this one, MAKEFLAGS > does > not contain O= options when the test is done so the issue is not appearing > there: > > adding: > @@ -116,6 +116,7 @@ endif > # If the user is running make -s (silent mode), suppress echoing of > # commands > > +$(info MAKEFLAGS=$(MAKEFLAGS)) > +$(info MFLAGS=$(MFLAGS)) > ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),) > quiet := silent_ > endif > > ## On linux with make 4.3 i see: > MAKEFLAGS=-rR > MFLAGS= > and the build is not silent > > with -s: > MAKEFLAGS=s -rR > MFLAGS=-s > > with --warn-undefined-variables > MAKEFLAGS= --warn-undefined-variables -rR > MFLAGS=--warn-undefined-variables > > ## but on linux with 4.4.1 i see (same with brew make 4.4.4: > MAKEFLAGS=rR -- XEN_TARGET_ARCH=arm64 O=builddir-s-test > MFLAGS=-rR > and the build is silent > > with -s: > MAKEFLAGS=rRs -- XEN_TARGET_ARCH=arm64 O=/home/bermar01/Work/xen/xen/builddir > MFLAGS=-rRs > > with --warn-undefined-variables > MAKEFLAGS=rR --warn-undefined-variables -- XEN_TARGET_ARCH=arm64 > O=/home/bermar01/Work/xen/xen/builddir > MFLAGS=-rR --warn-undefined-variables
Ah yes, and here is a quote from make 4.4's NEWS: "* WARNING: Backward-incompatibility! Previously only simple (one-letter) options were added to the MAKEFLAGS variable that was visible while parsing makefiles. Now, all options are available in MAKEFLAGS. If you want to check MAKEFLAGS for a one-letter option, expanding "$(firstword -$(MAKEFLAGS))" is a reliable way to return the set of one-letter options which can be examined via findstring, etc." > So i think the working solution would be to keep the current test but do it > on MFLAGS instead of MAKEFLAGS: > > ifneq ($(findstring s,$(filter-out --%,$(MFLAGS))),) > quiet := silent_ > endif > > Could you quickly do the same test than me on make 4.0 and 4.2.1 to confirm ? Well, I did confirm this already with my earlier experimenting. IOW either this or the $(firstword -$(MAKEFLAGS)) they suggest (effectively matching my earlier suggestion, prepending '.' instead of '-', as really any char other than 's' or a whitespace one will do here). Personally I'm slightly in favor of the MFLAGS variant. Jan
