| Message ID | 20200822212129.97758-4-r.bolshakov@yadro.com |
|---|---|
| State | New |
| Headers | show |
| Series | Compatibility make fixes for meson | expand |
On Sun, Aug 23, 2020 at 12:21:28AM +0300, 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. > > With the change, 'make' switches over to gmake implicitly. > > Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> > --- > configure | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/configure b/configure > index 9e0d505067..90b02b7271 100755 > --- a/configure > +++ b/configure > @@ -903,6 +903,7 @@ Darwin) > darwin="yes" > hax="yes" > hvf="yes" > + make="${MAKE-gmake}" > LDFLAGS_SHARED="-bundle -undefined dynamic_lookup" > if [ "$cpu" = "x86_64" ] ; then > QEMU_CFLAGS="-arch x86_64 $QEMU_CFLAGS" > @@ -916,6 +917,27 @@ Darwin) > # won't work when we're compiling with gcc as a C compiler. > QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS" > HOST_VARIANT_DIR="darwin" > + cat > GNUmakefile <<'EOF' > +# This file is auto-generated by configure to implicitly switch from a 'make' > +# invocation to 'gmake' > + > +OLD_MAKE := $(MAKE) > + > +include config-host.mak > + > +ifeq ($(MAKECMDGOALS),) > +recurse: all > +endif > + > +.NOTPARALLEL: % > +%: force > + @echo 'Switch from $(OLD_MAKE) to $(MAKE)' > + @$(MAKE) -f Makefile $(MAKECMDGOALS) > +force: ; > +.PHONY: force > +GNUmakefile: ; > + > +EOF I was wondering why you duplicated the GNUmakefile I created earlier, then I realized this one is created in the build dir, whereas the other was created in the source dir. I would note this works for macOS which has a GNU make, but doesn't work for FreeBSD has non-GNU make by default. I kind of feel like the previous patch which raises an error is good enough. User can just put the homebrew newer GNU make first in their $PATH, which is sensible regardless IMHO. None the less, this patch does what it claims so Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Regards, Daniel
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? > > With the change, 'make' switches over to gmake implicitly. If gmake ships new enough by default, then this seems like a slick trick, although I am not in a position to test it. > @@ -916,6 +917,27 @@ Darwin) > # won't work when we're compiling with gcc as a C compiler. > QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS" > HOST_VARIANT_DIR="darwin" > + cat > GNUmakefile <<'EOF' > +# This file is auto-generated by configure to implicitly switch from a 'make' > +# invocation to 'gmake' Are we going to run into issues with an in-tree build trying to create GNUmakefile to switch over to build/, while also creating build/GNUmakefile to switch from make to gmake?
On Mon, Aug 24, 2020 at 09:49:33AM -0500, Eric Blake 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? > > > > > With the change, 'make' switches over to gmake implicitly. > > If gmake ships new enough by default, then this seems like a slick trick, > although I am not in a position to test it. > > > @@ -916,6 +917,27 @@ Darwin) > > # won't work when we're compiling with gcc as a C compiler. > > QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS" > > HOST_VARIANT_DIR="darwin" > > + cat > GNUmakefile <<'EOF' > > +# This file is auto-generated by configure to implicitly switch from a 'make' > > +# invocation to 'gmake' > > Are we going to run into issues with an in-tree build trying to create > GNUmakefile to switch over to build/, while also creating build/GNUmakefile > to switch from make to gmake? Don't think so - it just means we'll go through both GNUmakefile in turn before getting to the real Makefile. Regards, Daniel
On 8/24/20 9:51 AM, Daniel P. Berrangé wrote: >>> @@ -916,6 +917,27 @@ Darwin) >>> # won't work when we're compiling with gcc as a C compiler. >>> QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS" >>> HOST_VARIANT_DIR="darwin" >>> + cat > GNUmakefile <<'EOF' >>> +# This file is auto-generated by configure to implicitly switch from a 'make' >>> +# invocation to 'gmake' >> >> Are we going to run into issues with an in-tree build trying to create >> GNUmakefile to switch over to build/, while also creating build/GNUmakefile >> to switch from make to gmake? > > Don't think so - it just means we'll go through both GNUmakefile in > turn before getting to the real Makefile. Actually, we won't - the top-level in-tree GNUmakefile calls $(MAKE) -C build -f Makefile, which means it skips build/GNUmakefile. But on the other hand, since this series adjusts both places to source build/config-host.mak, which in turn assigns $MAKE in a timely manner, the recursion should be run through the correct gmake whether done from the top-level or directly from within build.
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. thanks -- PMM
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
diff --git a/configure b/configure index 9e0d505067..90b02b7271 100755 --- a/configure +++ b/configure @@ -903,6 +903,7 @@ Darwin) darwin="yes" hax="yes" hvf="yes" + make="${MAKE-gmake}" LDFLAGS_SHARED="-bundle -undefined dynamic_lookup" if [ "$cpu" = "x86_64" ] ; then QEMU_CFLAGS="-arch x86_64 $QEMU_CFLAGS" @@ -916,6 +917,27 @@ Darwin) # won't work when we're compiling with gcc as a C compiler. QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS" HOST_VARIANT_DIR="darwin" + cat > GNUmakefile <<'EOF' +# This file is auto-generated by configure to implicitly switch from a 'make' +# invocation to 'gmake' + +OLD_MAKE := $(MAKE) + +include config-host.mak + +ifeq ($(MAKECMDGOALS),) +recurse: all +endif + +.NOTPARALLEL: % +%: force + @echo 'Switch from $(OLD_MAKE) to $(MAKE)' + @$(MAKE) -f Makefile $(MAKECMDGOALS) +force: ; +.PHONY: force +GNUmakefile: ; + +EOF ;; SunOS) solaris="yes"
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. With the change, 'make' switches over to gmake implicitly. Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> --- configure | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)