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

[Jan Beulich <jbeulich@xxxxxxxx>]

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
with O= I can't repro what you say. In fact with a Makefile containing just

$(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?

Jan