Hi Jan, > On 5 Feb 2026, at 09:56, Jan Beulich <[email protected]> wrote: > > 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."
Nice > >> 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. Agree, i will use MFLAGS as this looks more reliable. Thanks i will submit this and the mac os build thing as independent patches. Cheers Bertrand
