[PATCH 0/4] Compatibility make fixes for meson

[PATCH 0/4] Compatibility make fixes for meson

[Roman Bolshakov]

The set of changes addresses "Diagnose "make is too old" in configure
(or in the makefile?)" from https://wiki.qemu.org/Features/Meson#Easy.
It also provides cleaner backwards compatible build invocation on macOS.

Roman Bolshakov (4):
  configure: Use discovered make for in-source build
  Makefile: Require GNU make 3.82+
  configure: Prefer gmake on darwin
  configure: Test if $make actually exists

 Makefile  |  5 +++++
 configure | 28 ++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)

-- 
2.28.0

[PATCH 1/4] configure: Use discovered make for in-source build

[Roman Bolshakov]

A recursive make is inovked if in-source build is used but $(MAKE) is
the same as the one used in the original make invocaton.

Some platforms have preference to use gmake, or a make passed as an
option to "configure". Honor the choice.

Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
---
 configure | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index 4e5fe33211..9e0d505067 100755
--- a/configure
+++ b/configure
@@ -38,6 +38,8 @@ then
 # This file is auto-generated by configure to support in-source tree
 # 'make' command invocation
 
+include build/config-host.mak
+
 ifeq ($(MAKECMDGOALS),)
 recurse: all
 endif
-- 
2.28.0

Re: [PATCH 1/4] configure: Use discovered make for in-source build

[Daniel P. Berrangé]

On Sun, Aug 23, 2020 at 12:21:26AM +0300, Roman Bolshakov wrote:
> A recursive make is inovked if in-source build is used but $(MAKE) is
> the same as the one used in the original make invocaton.
> 
> Some platforms have preference to use gmake, or a make passed as an
> option to "configure". Honor the choice.
> 
> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
> ---
>  configure | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH 1/4] configure: Use discovered make for in-source build

[Eric Blake]

On 8/22/20 4:21 PM, Roman Bolshakov wrote:
> A recursive make is inovked if in-source build is used but $(MAKE) is
> the same as the one used in the original make invocaton.
> 
> Some platforms have preference to use gmake, or a make passed as an
> option to "configure". Honor the choice.
> 
> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
> ---
>   configure | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/configure b/configure
> index 4e5fe33211..9e0d505067 100755
> --- a/configure
> +++ b/configure
> @@ -38,6 +38,8 @@ then
>   # This file is auto-generated by configure to support in-source tree
>   # 'make' command invocation
>   
> +include build/config-host.mak

Should this use '-include' (also spelled 'sinclude'), to avoid halting 
the build if build/config-host.mak doesn't exist for whatever reason?

> +
>   ifeq ($(MAKECMDGOALS),)
>   recurse: all
>   endif
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: [PATCH 1/4] configure: Use discovered make for in-source build

[Roman Bolshakov]

On Mon, Aug 24, 2020 at 09:37:07AM -0500, Eric Blake wrote:
> On 8/22/20 4:21 PM, Roman Bolshakov wrote:
> > @@ -38,6 +38,8 @@ then
> >   # This file is auto-generated by configure to support in-source tree
> >   # 'make' command invocation
> > +include build/config-host.mak
> 
> Should this use '-include' (also spelled 'sinclude'), to avoid halting the
> build if build/config-host.mak doesn't exist for whatever reason?
> 

Sure I can do (and thanks for the noticed typos) but I tested that if
the build is interrupted too early (before Makefile is symlinked to
build directory but after GNUmakefile is created) it would fail even if
-include is used:

$ make
changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
make[1]: Makefile: No such file or directory
make[1]: *** No rule to make target `Makefile'.  Stop.
changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
make[1]: Makefile: No such file or directory
make[1]: *** No rule to make target `Makefile'.  Stop.
make: *** [all] Error 2

I'm also curious why the switch happens twice... According to the debug
trace, it tries to remake build/config-host.mak using the implicit force
rule:

GNUmakefile:12: update target 'build/config-host.mak' due to: force

Then there should be an explicit empty rule for build/config-host.mak. I
will send a fix for that in v2. Then it would fail like this:

$ make
changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
make[1]: Makefile: No such file or directory
make[1]: *** No rule to make target `Makefile'.  Stop.
make: *** [all] Error 2

Regards,
Roman

> > +
> >   ifeq ($(MAKECMDGOALS),)
> >   recurse: all
> >   endif
> > 
> 

Re: [PATCH 1/4] configure: Use discovered make for in-source build

[Roman Bolshakov]

On Tue, Aug 25, 2020 at 01:07:55AM +0300, Roman Bolshakov wrote:
> On Mon, Aug 24, 2020 at 09:37:07AM -0500, Eric Blake wrote:
> > On 8/22/20 4:21 PM, Roman Bolshakov wrote:
> > > @@ -38,6 +38,8 @@ then
> > >   # This file is auto-generated by configure to support in-source tree
> > >   # 'make' command invocation
> > > +include build/config-host.mak
> > 
> > Should this use '-include' (also spelled 'sinclude'), to avoid halting the
> > build if build/config-host.mak doesn't exist for whatever reason?
> > 
> 
> Sure I can do (and thanks for the noticed typos) but I tested that if
> the build is interrupted too early (before Makefile is symlinked to
> build directory but after GNUmakefile is created) it would fail even if
> -include is used:
> 
> $ make
> changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
> make[1]: Makefile: No such file or directory
> make[1]: *** No rule to make target `Makefile'.  Stop.
> changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
> make[1]: Makefile: No such file or directory
> make[1]: *** No rule to make target `Makefile'.  Stop.
> make: *** [all] Error 2
> 
> I'm also curious why the switch happens twice... According to the debug
> trace, it tries to remake build/config-host.mak using the implicit force
> rule:
> 
> GNUmakefile:12: update target 'build/config-host.mak' due to: force
> 
> Then there should be an explicit empty rule for build/config-host.mak. I
> will send a fix for that in v2. Then it would fail like this:
> 
> $ make
> changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""...
> make[1]: Makefile: No such file or directory
> make[1]: *** No rule to make target `Makefile'.  Stop.
> make: *** [all] Error 2
> 
> > > +
> > >   ifeq ($(MAKECMDGOALS),)
> > >   recurse: all
> > >   endif
> > > 
> > 

Hi Eric,

What if we just print an error if build/config-host.mak can't be found?

ifeq ($(wildcard build/config-host.mak),)
$(error "Incomplete configuration. Please run ./configure")
endif

IMO this is more sane approach than proceeding with partially-configured
not working build without a Makefile in proper place.

Regards,
Roman

Re: [PATCH 1/4] configure: Use discovered make for in-source build

[Eric Blake]

On 8/25/20 5:16 AM, Roman Bolshakov wrote:

> 
> Hi Eric,
> 
> What if we just print an error if build/config-host.mak can't be found?
> 
> ifeq ($(wildcard build/config-host.mak),)
> $(error "Incomplete configuration. Please run ./configure")
> endif
> 
> IMO this is more sane approach than proceeding with partially-configured
> not working build without a Makefile in proper place.

Yes, that is definitely a better approach.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: [PATCH 1/4] configure: Use discovered make for in-source build

[Eric Blake]

On 8/22/20 4:21 PM, Roman Bolshakov wrote:
> A recursive make is inovked if in-source build is used but $(MAKE) is

invoked

> the same as the one used in the original make invocaton.

invocation

> 
> Some platforms have preference to use gmake, or a make passed as an
> option to "configure". Honor the choice.
> 
> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
> ---
>   configure | 2 ++
>   1 file changed, 2 insertions(+)
> 


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

[PATCH 2/4] Makefile: Require GNU make 3.82+

[Roman Bolshakov]

QEMU build fails with cryptic messages if make is too old:

  Makefile.ninja:2655: *** multiple target patterns.  Stop.

To avoid the confusion it's worth to fail the build right away and print
a friendly error message.

Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
---
 Makefile | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Makefile b/Makefile
index 8373ddccc9..45d688b87b 100644
--- a/Makefile
+++ b/Makefile
@@ -4,6 +4,11 @@ ifneq ($(words $(subst :, ,$(CURDIR))), 1)
   $(error main directory cannot contain spaces nor colons)
 endif
 
+ifeq ($(filter undefine,$(value .FEATURES)),)
+$(error Unsupported Make version: $(MAKE_VERSION). \
+        Please use GNU Make 3.82 or above)
+endif
+
 # Always point to the root of the build tree (needs GNU make).
 BUILD_DIR=$(CURDIR)
 
-- 
2.28.0

Re: [PATCH 2/4] Makefile: Require GNU make 3.82+

[Daniel P. Berrangé]

On Sun, Aug 23, 2020 at 12:21:27AM +0300, Roman Bolshakov wrote:
> QEMU build fails with cryptic messages if make is too old:
> 
>   Makefile.ninja:2655: *** multiple target patterns.  Stop.
> 
> To avoid the confusion it's worth to fail the build right away and print
> a friendly error message.
> 
> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
> ---
>  Makefile | 5 +++++
>  1 file changed, 5 insertions(+)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Roman Bolshakov]

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
 ;;
 SunOS)
   solaris="yes"
-- 
2.28.0

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

[Daniel P. Berrangé]

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Eric Blake]

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?


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

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

[Daniel P. Berrangé]

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Eric Blake]

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.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

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

[Peter Maydell]

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

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

[Roman Bolshakov]

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

[PATCH 4/4] configure: Test if $make actually exists

[Roman Bolshakov]

configure doesn't detect if $make is installed on the build host.
This is also helpful for hosts where an alias for make is used, i.e.
configure would fail if gmake is not present on macOS.

Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
---
 configure | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/configure b/configure
index 90b02b7271..c324252f60 100755
--- a/configure
+++ b/configure
@@ -2021,6 +2021,10 @@ if test -z "$python"
 then
     error_exit "Python not found. Use --python=/path/to/python"
 fi
+if ! has "$make"
+then
+    error_exit "GNU make ($make) not found"
+fi
 
 # Note that if the Python conditional here evaluates True we will exit
 # with status 1 which is a shell 'false' value.
-- 
2.28.0

Re: [PATCH 4/4] configure: Test if $make actually exists

[Daniel P. Berrangé]

On Sun, Aug 23, 2020 at 12:21:29AM +0300, Roman Bolshakov wrote:
> configure doesn't detect if $make is installed on the build host.
> This is also helpful for hosts where an alias for make is used, i.e.
> configure would fail if gmake is not present on macOS.
> 
> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
> ---
>  configure | 4 ++++
>  1 file changed, 4 insertions(+)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|