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

[Jan Beulich <jbeulich@xxxxxxxx>]

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."

> 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