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.

Add a minimal Darwin configuration, document the Homebrew toolchain and
PATH setup (including prefix differences and an out-of-tree example), and
clarify that the guide is tested on arm64. Tighten silent-mode detection
to only look at the short option word.

Functional impact: The Xen hypervisor can be cross-built on macOS (arm64)
with the documented Homebrew toolchain, and make output is no longer forced
silent by --include-dir paths.

Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
---
This patch does not intent to say that building on mac os is supported
but it can be helpful for people developing on mac os (I have been using
that for a while) and is solving a Makefile issue that could be hit by
others in other environments.
The doc file is quick attempt to document that for others, happy to get
comments from others to find out if they think this is useful or not or
if this should not be documented there.
---
 config/Darwin.mk            |  4 +++
 docs/misc/build-on-macos.md | 66 +++++++++++++++++++++++++++++++++++++
 xen/Makefile                |  2 +-
 3 files changed, 71 insertions(+), 1 deletion(-)
 create mode 100644 config/Darwin.mk
 create mode 100644 docs/misc/build-on-macos.md

diff --git a/config/Darwin.mk b/config/Darwin.mk
new file mode 100644
index 000000000000..64a1dfcb42ed
--- /dev/null
+++ b/config/Darwin.mk
@@ -0,0 +1,4 @@
+include $(XEN_ROOT)/config/StdGNU.mk
+
+# We are always cross compiling so fake COMPILE_ARCH
+XEN_COMPILE_ARCH = Darwin
diff --git a/docs/misc/build-on-macos.md b/docs/misc/build-on-macos.md
new file mode 100644
index 000000000000..6b56cd8eccab
--- /dev/null
+++ b/docs/misc/build-on-macos.md
@@ -0,0 +1,66 @@
+# Building Xen Hypervisor on macOS
+
+This guide explains how to cross-compile the Xen hypervisor (xen
+subdirectory only) on macOS. This does **not** build the tools.
+
+## Prerequisites
+
+Install the following packages using Homebrew:
+
+```bash
+# Cross-compilation toolchain for ARM64
+brew install aarch64-elf-gcc
+
+# GNU tools (required for compatibility)
+brew install make gnu-sed
+```
+
+Homebrew installs under `/opt/homebrew` on Apple Silicon and `/usr/local` on
+Intel Macs. Adjust paths below accordingly.
+
+### Verification
+
+Verify your installation:
+
+```bash
+# Check cross compiler
+aarch64-elf-gcc --version
+
+# Check GNU make (adjust prefix if needed)
+/opt/homebrew/opt/make/libexec/gnubin/make --version
+
+# Check GNU sed (adjust prefix if needed)
+/opt/homebrew/opt/gnu-sed/libexec/gnubin/sed --version
+```
+
+## Building the Hypervisor
+
+Set up GNU tools in PATH and build:
+
+```bash
+# Set up GNU tools in PATH (adjust prefix if needed)
+export PATH="/opt/homebrew/opt/gnu-sed/libexec/gnubin:/opt/homebrew/opt/make/libexec/gnubin:$PATH"
+
+# Build Xen hypervisor only (in-tree)
+cd xen/
+make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=gcc
+
+# Optional: out-of-tree build directory
+# make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=gcc O=$PWD/build-mac
+```
+
+## Architecture Support
+
+Currently supported architectures:
+
+- **ARM64** (`arm64`) - Default, uses `aarch64-elf-gcc`
+
+Other targets may work if the corresponding cross toolchain is installed,
+but this guide has only been tested on ARM64.
+
+## Limitations
+
+- **Hypervisor only**: This only builds the Xen hypervisor, not the tools
+- **Cross-compilation only**: Native builds are not supported
+- **macOS-specific**: Instructions optimized for macOS with Homebrew
+- **GNU tools required**: Native BSD tools are not compatible
diff --git a/xen/Makefile b/xen/Makefile
index 13e336ba5484..adeb869f32ad 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -116,7 +116,7 @@ endif
 # If the user is running make -s (silent mode), suppress echoing of
 # commands
 
-ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),)
+ifneq ($(findstring s,$(firstword $(MAKEFLAGS))),)
     quiet := silent_
 endif
 
-- 
2.52.0

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.

> --- /dev/null
> +++ b/config/Darwin.mk
> @@ -0,0 +1,4 @@
> +include $(XEN_ROOT)/config/StdGNU.mk

Darwin isn't really a GNU environment, is it? The definitions in that file
may be suitable, but perhaps a brief comment is warranted?

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -116,7 +116,7 @@ endif
>  # If the user is running make -s (silent mode), suppress echoing of
>  # commands
>  
> -ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),)
> +ifneq ($(findstring s,$(firstword $(MAKEFLAGS))),)

While probably this would do, assuming make isn't going to make drastic
changes to how $(MAKEFLAGS) is set up, how about

-ifneq ($(findstring s,$(filter-out -%,$(MAKEFLAGS))),)

instead?

Jan

On Wed, Feb 04, 2026 at 04:31:12PM +0100, Jan Beulich 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.
> 
> > --- /dev/null
> > +++ b/config/Darwin.mk
> > @@ -0,0 +1,4 @@
> > +include $(XEN_ROOT)/config/StdGNU.mk
> 
> Darwin isn't really a GNU environment, is it? The definitions in that file
> may be suitable, but perhaps a brief comment is warranted?

It's similar to FreeBSD in that regard, which is also not a GNU
environment as the compiler and toolchain is LLVM.  However the LLVM
toolchain attempt to be command line and output compatible with the
GNU one AFAIK.

FreeBSD.mk also includes StdGNU.mk.  Maybe we want to rename StdGNU.mk
to generic.mk or common.mk?

Thanks, Roger.

On 04.02.2026 17:22, Roger Pau Monné wrote:
> On Wed, Feb 04, 2026 at 04:31:12PM +0100, Jan Beulich wrote:
>> On 04.02.2026 14:16, Bertrand Marquis wrote:
>>> --- /dev/null
>>> +++ b/config/Darwin.mk
>>> @@ -0,0 +1,4 @@
>>> +include $(XEN_ROOT)/config/StdGNU.mk
>>
>> Darwin isn't really a GNU environment, is it? The definitions in that file
>> may be suitable, but perhaps a brief comment is warranted?
> 
> It's similar to FreeBSD in that regard, which is also not a GNU
> environment as the compiler and toolchain is LLVM.  However the LLVM
> toolchain attempt to be command line and output compatible with the
> GNU one AFAIK.

Hmm, FreeBSD (unlike OpenBSD and NetBSD) may be somewhat complicated in this
regard. First, I don't think the default compiler used matters. What does
matter is behavior in certain (many?) respects. E.g. in GNU binutils
ELFOSABI_FREEBSD is treated as equivalent to ELFOSABI_GNU in certain places.
So it may be viewed as a "hybrid"? (Of course there are many(?) other things
where GNU environments are expected to "behave" in certain ways.)

> FreeBSD.mk also includes StdGNU.mk.  Maybe we want to rename StdGNU.mk
> to generic.mk or common.mk?

Not sure here.

Jan

Hi Jan,

> On 4 Feb 2026, at 16:31, Jan Beulich <jbeulich@suse.com> 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.

I was not thinking as this being a candidate for backport as the only
consequence is that if you have a s in the full path to the xen tree your
build will be silent even if you pass V=1 or Q= to make but things will
still build.

But i will split that as a standalone patch.

> 
>> --- /dev/null
>> +++ b/config/Darwin.mk
>> @@ -0,0 +1,4 @@
>> +include $(XEN_ROOT)/config/StdGNU.mk
> 
> Darwin isn't really a GNU environment, is it? The definitions in that file
> may be suitable, but perhaps a brief comment is warranted?

Yes this is only valid because we use brew in that case.
I will add a comment.

> 
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -116,7 +116,7 @@ endif
>> # If the user is running make -s (silent mode), suppress echoing of
>> # commands
>> 
>> -ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),)
>> +ifneq ($(findstring s,$(firstword $(MAKEFLAGS))),)
> 
> While probably this would do, assuming make isn't going to make drastic
> changes to how $(MAKEFLAGS) is set up, how about
> 
> -ifneq ($(findstring s,$(filter-out -%,$(MAKEFLAGS))),)
> 
> instead?

Yes this is a solution that should work to, making the assumption that short
arguments are kept at the beginning like they are now is possibly to strong.

I will test and check that and submit submit 2 independent patches.

Cheers
Bertrand

> 
> Jan

On 04.02.2026 16:45, Bertrand Marquis wrote:
>> On 4 Feb 2026, at 16:31, Jan Beulich <jbeulich@suse.com> wrote:
>> On 04.02.2026 14:16, Bertrand Marquis wrote:
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -116,7 +116,7 @@ endif
>>> # If the user is running make -s (silent mode), suppress echoing of
>>> # commands
>>>
>>> -ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),)
>>> +ifneq ($(findstring s,$(firstword $(MAKEFLAGS))),)
>>
>> While probably this would do, assuming make isn't going to make drastic
>> changes to how $(MAKEFLAGS) is set up, how about
>>
>> -ifneq ($(findstring s,$(filter-out -%,$(MAKEFLAGS))),)
>>
>> instead?
> 
> Yes this is a solution that should work to, making the assumption that short
> arguments are kept at the beginning like they are now is possibly to strong.

As you indicated on Matrix, this wouldn't cover variable definitions, e.g. O=.
Sticking to just $(firstword ...) also doesn't work, though: If there are no
options needing handing on and having a short form representation, the "first
word" may be empty, with $(MAKEFLAGS) then starting with a blank. Perhaps

ifneq ($(findstring s,$(firstword .$(MAKEFLAGS))),)

would be a way to overcome this.

However, wording in the documentation [1], [2] is ambiguous as to whether we
may rely on there being that leading blank (it seems likely that [1] is more
reliable than [2], but still). However, [2] effectively suggests another
alternative:

ifneq ($(findstring s,$(filter-out --%,$(MFLAGS))),)

While you meanwhile clarified (again on Matrix) that use of -I isn't the
culprit, even with O= I still cannot observe the behavior you're describing.
I.e. I still need to pass -s in order to silence the build, even if I use
O=.../staging (i.e. an 's' clearly being present in the path).

Jan

[1] "If there are no single-letter options on the command line, then the value
     of MAKEFLAGS starts with a space."

[2] "A similar variable MFLAGS exists also, for historical compatibility. It
     has the same value as MAKEFLAGS except that it does not contain the
     command line variable definitions, and it always begins with a hyphen
     unless it is empty (MAKEFLAGS begins with a hyphen only when it begins
     with an option that has no single-letter version, such as
     ‘--warn-undefined-variables’)."

On Wed, Feb 04, 2026 at 03:45:33PM +0000, Bertrand Marquis wrote:
> Hi Jan,
> 
> > On 4 Feb 2026, at 16:31, Jan Beulich <jbeulich@suse.com> wrote:
> > 
> > On 04.02.2026 14:16, Bertrand Marquis wrote:
> >> --- /dev/null
> >> +++ b/config/Darwin.mk
> >> @@ -0,0 +1,4 @@
> >> +include $(XEN_ROOT)/config/StdGNU.mk
> > 
> > Darwin isn't really a GNU environment, is it? The definitions in that file
> > may be suitable, but perhaps a brief comment is warranted?
> 
> Yes this is only valid because we use brew in that case.
> I will add a comment.

Oh, so you end up building using the GNU toolchain provided by
homebrew and not the LLVM one?  Sorry, I was assuming that you did use
the native LLVM toolchain when possible.

Thanks, Roger.

Hi Roger,

> On 4 Feb 2026, at 17:24, Roger Pau Monné <roger.pau@citrix.com> wrote:
> 
> On Wed, Feb 04, 2026 at 03:45:33PM +0000, Bertrand Marquis wrote:
>> Hi Jan,
>> 
>>> On 4 Feb 2026, at 16:31, Jan Beulich <jbeulich@suse.com> wrote:
>>> 
>>> On 04.02.2026 14:16, Bertrand Marquis wrote:
>>>> --- /dev/null
>>>> +++ b/config/Darwin.mk
>>>> @@ -0,0 +1,4 @@
>>>> +include $(XEN_ROOT)/config/StdGNU.mk
>>> 
>>> Darwin isn't really a GNU environment, is it? The definitions in that file
>>> may be suitable, but perhaps a brief comment is warranted?
>> 
>> Yes this is only valid because we use brew in that case.
>> I will add a comment.
> 
> Oh, so you end up building using the GNU toolchain provided by
> homebrew and not the LLVM one?  Sorry, I was assuming that you did use
> the native LLVM toolchain when possible.

I am using the GNU toolchain using brew.

That would also work using LLVM i guess but the dependency on other GNU
tools like make and sed would still be there so you would need brew (or something
else providing gnu make and sed for our build to work).

In any case you would require to include StdGNU.mk anyway.

I am not sure if renaming it is a good idea as you need something GNU friendly
even if it is not a GNU thing so ....

Cheers
Bertrand

> 
> Thanks, Roger.

On Wed, Feb 04, 2026 at 04:51:35PM +0000, Bertrand Marquis wrote:
> Hi Roger,
> 
> > On 4 Feb 2026, at 17:24, Roger Pau Monné <roger.pau@citrix.com> wrote:
> > 
> > On Wed, Feb 04, 2026 at 03:45:33PM +0000, Bertrand Marquis wrote:
> >> Hi Jan,
> >> 
> >>> On 4 Feb 2026, at 16:31, Jan Beulich <jbeulich@suse.com> wrote:
> >>> 
> >>> On 04.02.2026 14:16, Bertrand Marquis wrote:
> >>>> --- /dev/null
> >>>> +++ b/config/Darwin.mk
> >>>> @@ -0,0 +1,4 @@
> >>>> +include $(XEN_ROOT)/config/StdGNU.mk
> >>> 
> >>> Darwin isn't really a GNU environment, is it? The definitions in that file
> >>> may be suitable, but perhaps a brief comment is warranted?
> >> 
> >> Yes this is only valid because we use brew in that case.
> >> I will add a comment.
> > 
> > Oh, so you end up building using the GNU toolchain provided by
> > homebrew and not the LLVM one?  Sorry, I was assuming that you did use
> > the native LLVM toolchain when possible.
> 
> I am using the GNU toolchain using brew.
> 
> That would also work using LLVM i guess but the dependency on other GNU
> tools like make and sed would still be there so you would need brew (or something
> else providing gnu make and sed for our build to work).

GNU make is provided by OSX Command Line tools, you shouldn't need to
install it from homebrew.  Same with sed, the one provided by OS X
which is FreeBSD sed should work with the Xen build system (at least
on x86 we attempt to not use GNU extensions to sed).

However, I don't know whether the LLVM toolchain in OS X will be
capable of producing ELF binaries - most likely not, it's likely
limited to the OS X Mach-O format.

> In any case you would require to include StdGNU.mk anyway.
> 
> I am not sure if renaming it is a good idea as you need something GNU friendly
> even if it is not a GNU thing so ....

Hm, yes, it's a POSIX environment plus a GNU compatible toolchain.

Thanks, Roger.

On 04.02.2026 16:45, Bertrand Marquis wrote:
>> On 4 Feb 2026, at 16:31, Jan Beulich <jbeulich@suse.com> 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.

Jan

Hi Jan,

> On 4 Feb 2026, at 17:15, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 04.02.2026 16:45, Bertrand Marquis wrote:
>>> On 4 Feb 2026, at 16:31, Jan Beulich <jbeulich@suse.com> 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.

Cheers
Bertrand

> 
> Jan

On 05.02.2026 08:44, Bertrand Marquis wrote:
>> On 4 Feb 2026, at 17:15, Jan Beulich <jbeulich@suse.com> wrote:
>> On 04.02.2026 16:45, Bertrand Marquis wrote:
>>>> On 4 Feb 2026, at 16:31, Jan Beulich <jbeulich@suse.com> 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

Hi Jan,

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

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

Hi Jan,

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