Re: [RFC PATCH] xen: Add macOS hypervisor build support

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Jan,

> On 5 Feb 2026, at 09:56, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 05.02.2026 09:44, Bertrand Marquis wrote:
>> Hi Jan,
>> 
>>> On 5 Feb 2026, at 09:23, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>> On 05.02.2026 08:44, Bertrand Marquis wrote:
>>>>> On 4 Feb 2026, at 17:15, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>> On 04.02.2026 16:45, Bertrand Marquis wrote:
>>>>>>> On 4 Feb 2026, at 16:31, Jan Beulich <jbeulich@xxxxxxxx> 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