qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/4] configure: Prefer gmake on darwin


From: Roman Bolshakov
Subject: Re: [PATCH 3/4] configure: Prefer gmake on darwin
Date: Tue, 25 Aug 2020 12:25:30 +0300

On Mon, Aug 24, 2020 at 04:57:31PM +0100, Peter Maydell wrote:
> On Mon, 24 Aug 2020 at 15:51, Eric Blake <eblake@redhat.com> wrote:
> >
> > On 8/22/20 4:21 PM, Roman Bolshakov wrote:
> > > New meson/make build requires GNU make 3.82+ but macOS ships 3.81 even
> > > on Big Sur while homebrew provides GNU make 4.3 as 'gmake' in $PATH.
> >
> > Does this line up with our development policies on supported platforms?
> > Should we be fixing the creation of Makefile.ninja to avoid constructs
> > not understood by older GNU make, if that is what is shipped out of the
> > box on MacOS as one of our supported platforms?  Or is MacOS on the
> > fringe for what counts as supported, where we are okay mandating that
> > users must install a separate newer GNU make than what comes by default?
> 
> If it's easy to add back support for make 3.81 that would be the
> nicest thing, I think. But we already require the user to install
> a non-system python, for instance, so asking them to also install
> make from homebrew isn't a completely new thing. (The only awkward
> thing is that homebrew doesn't actually put the new make on the
> path as 'make', only as 'gmake', so you have to then manually
> fiddle the PATH.) At some point requiring some tools from homebrew
> or similar for QEMU compilation is just inevitable given
> Apple's apparent policy of never moving the system versions of
> tools beyond the last GPLv2 version.
> 

Never thought of that, but perhaps it's similar to what happened with
bash. Apple shipped an old GPLv2 version of bash (3.2) for quite a while
even after 4.x release. Then they suddenly switched default shell to
zsh. Following the approach, we're more likely to see meson and ninja in
Apple Command Line Tools than GNU Make 3.82+ 🙂

As for alias, Homebrew also provides GNU coreutils and sed with g
prefix and a special gnubin prefix is provided to simplify bulk addition
of GNU tools to PATH, so it's consistent in some sense :)

Here's a related homebrew discussion about system binary shadowing:
https://discourse.brew.sh/t/why-was-with-default-names-removed/4405/14

-Roman



reply via email to

[Prev in Thread] Current Thread [Next in Thread]