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

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

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

Giving --silent is giving the same MAKEFLAGS and MFLAGS on both versions.

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 ?

Cheers
Bertrand