Documentation/process/changes.rst notes the minimal GNU Make version,
but it is not checked anywhere.
We could check $(MAKE_VERSION), but another simple way is to check
$(.FEATURES) since the feature list always grows although this way
is not always possible. For example Make 4.0 through 4.2 have the
same set of $(.FEATURES).
Signed-off-by: Masahiro Yamada <[email protected]>
---
Changes in v3:
- Check the version in a different way
Makefile | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Makefile b/Makefile
index 2dda1e9a717a..66dfc5751470 100644
--- a/Makefile
+++ b/Makefile
@@ -11,6 +11,11 @@ NAME = Hurr durr I'ma ninja sloth
# Comments in this file are targeted only to the developer, do not
# expect to learn how to build the kernel reading this file.
+# Ensure Make >= 3.82
+ifeq ($(filter undefine,$(.FEATURES)),)
+$(error Make $(MAKE_VERSION) is too old)
+endif
+
$(if $(filter __%, $(MAKECMDGOALS)), \
$(error targets prefixed with '__' are only for internal use))
--
2.34.1
On Sun, Dec 11, 2022 at 12:03:52PM +0900, Masahiro Yamada wrote:
> Documentation/process/changes.rst notes the minimal GNU Make version,
> but it is not checked anywhere.
>
> We could check $(MAKE_VERSION), but another simple way is to check
> $(.FEATURES) since the feature list always grows although this way
> is not always possible. For example Make 4.0 through 4.2 have the
> same set of $(.FEATURES).
>
> Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
> ---
>
> Changes in v3:
> - Check the version in a different way
>
> Makefile | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 2dda1e9a717a..66dfc5751470 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -11,6 +11,11 @@ NAME = Hurr durr I'ma ninja sloth
> # Comments in this file are targeted only to the developer, do not
> # expect to learn how to build the kernel reading this file.
>
> +# Ensure Make >= 3.82
> +ifeq ($(filter undefine,$(.FEATURES)),)
> +$(error Make $(MAKE_VERSION) is too old)
Would it make sense to state what version is needed, similar to the
Kconfig checks for compiler and binutils?
> +endif
> +
> $(if $(filter __%, $(MAKECMDGOALS)), \
> $(error targets prefixed with '__' are only for internal use))
>
> --
> 2.34.1
>
On Mon 12 Dec 2022 10:21:10 GMT, Nathan Chancellor wrote:
> On Sun, Dec 11, 2022 at 12:03:52PM +0900, Masahiro Yamada wrote:
> > Documentation/process/changes.rst notes the minimal GNU Make version,
> > but it is not checked anywhere.
> >
> > We could check $(MAKE_VERSION), but another simple way is to check
> > $(.FEATURES) since the feature list always grows although this way
> > is not always possible. For example Make 4.0 through 4.2 have the
> > same set of $(.FEATURES).
> >
> > Signed-off-by: Masahiro Yamada <[email protected]>
>
> Reviewed-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
> > ---
> >
> > Changes in v3:
> > - Check the version in a different way
> >
> > Makefile | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index 2dda1e9a717a..66dfc5751470 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -11,6 +11,11 @@ NAME = Hurr durr I'ma ninja sloth
> > # Comments in this file are targeted only to the developer, do not
> > # expect to learn how to build the kernel reading this file.
> >
> > +# Ensure Make >= 3.82
> > +ifeq ($(filter undefine,$(.FEATURES)),)
> > +$(error Make $(MAKE_VERSION) is too old)
>
> Would it make sense to state what version is needed, similar to the
> Kconfig checks for compiler and binutils?
Checking against 'undefine' (introduced in make-3.82~38) is quite a
nice way, I think. Otherwise we needed something like
$(filter 3.82% 3.9% 4.% 5.% ..., $(MAKE_VERSION)).
Kind regards,
Nicolas
On Tue, Dec 13, 2022 at 04:58:30AM +0100 Nicolas Schier wrote:
> On Mon 12 Dec 2022 10:21:10 GMT, Nathan Chancellor wrote:
> > On Sun, Dec 11, 2022 at 12:03:52PM +0900, Masahiro Yamada wrote:
> > > Documentation/process/changes.rst notes the minimal GNU Make version,
> > > but it is not checked anywhere.
> > >
> > > We could check $(MAKE_VERSION), but another simple way is to check
> > > $(.FEATURES) since the feature list always grows although this way
> > > is not always possible. For example Make 4.0 through 4.2 have the
> > > same set of $(.FEATURES).
> > >
> > > Signed-off-by: Masahiro Yamada <[email protected]>
> >
> > Reviewed-by: Nathan Chancellor <[email protected]>
>
> Reviewed-by: Nicolas Schier <[email protected]>
>
> > > ---
> > >
> > > Changes in v3:
> > > - Check the version in a different way
> > >
> > > Makefile | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 2dda1e9a717a..66dfc5751470 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -11,6 +11,11 @@ NAME = Hurr durr I'ma ninja sloth
> > > # Comments in this file are targeted only to the developer, do not
> > > # expect to learn how to build the kernel reading this file.
> > >
> > > +# Ensure Make >= 3.82
> > > +ifeq ($(filter undefine,$(.FEATURES)),)
> > > +$(error Make $(MAKE_VERSION) is too old)
> >
> > Would it make sense to state what version is needed, similar to the
> > Kconfig checks for compiler and binutils?
>
> Checking against 'undefine' (introduced in make-3.82~38) is quite a
> nice way, I think. Otherwise we needed something like
> $(filter 3.82% 3.9% 4.% 5.% ..., $(MAKE_VERSION)).
>
Nathan, sorry, I somehow I read your question completely wrong. I would also
appreciate if the minimum make version would be shown in the error message.
Kind regards,
Nicolas
On Tue, Dec 13, 2022 at 11:05:05AM +0100, Nicolas Schier wrote:
> On Tue, Dec 13, 2022 at 04:58:30AM +0100 Nicolas Schier wrote:
> > On Mon 12 Dec 2022 10:21:10 GMT, Nathan Chancellor wrote:
> > > On Sun, Dec 11, 2022 at 12:03:52PM +0900, Masahiro Yamada wrote:
> > > > Documentation/process/changes.rst notes the minimal GNU Make version,
> > > > but it is not checked anywhere.
> > > >
> > > > We could check $(MAKE_VERSION), but another simple way is to check
> > > > $(.FEATURES) since the feature list always grows although this way
> > > > is not always possible. For example Make 4.0 through 4.2 have the
> > > > same set of $(.FEATURES).
> > > >
> > > > Signed-off-by: Masahiro Yamada <[email protected]>
> > >
> > > Reviewed-by: Nathan Chancellor <[email protected]>
> >
> > Reviewed-by: Nicolas Schier <[email protected]>
> >
> > > > ---
> > > >
> > > > Changes in v3:
> > > > - Check the version in a different way
> > > >
> > > > Makefile | 5 +++++
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index 2dda1e9a717a..66dfc5751470 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -11,6 +11,11 @@ NAME = Hurr durr I'ma ninja sloth
> > > > # Comments in this file are targeted only to the developer, do not
> > > > # expect to learn how to build the kernel reading this file.
> > > >
> > > > +# Ensure Make >= 3.82
> > > > +ifeq ($(filter undefine,$(.FEATURES)),)
> > > > +$(error Make $(MAKE_VERSION) is too old)
> > >
> > > Would it make sense to state what version is needed, similar to the
> > > Kconfig checks for compiler and binutils?
> >
> > Checking against 'undefine' (introduced in make-3.82~38) is quite a
> > nice way, I think. Otherwise we needed something like
> > $(filter 3.82% 3.9% 4.% 5.% ..., $(MAKE_VERSION)).
> >
>
> Nathan, sorry, I somehow I read your question completely wrong. I would also
> appreciate if the minimum make version would be shown in the error message.
No worries, I have done that many a time :) I see Masahiro updated this
to v4 with this feedback taken into consideration so I am glad to see
we are all in agreement.
Cheers,
Nathan
From: Nicolas Schier
> Sent: 13 December 2022 03:59
...
> > > diff --git a/Makefile b/Makefile
> > > index 2dda1e9a717a..66dfc5751470 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -11,6 +11,11 @@ NAME = Hurr durr I'ma ninja sloth
> > > # Comments in this file are targeted only to the developer, do not
> > > # expect to learn how to build the kernel reading this file.
> > >
> > > +# Ensure Make >= 3.82
Wouldn't it be better to say either:
# Ensure gmake supports 'undefine' (added in 3.82)
or:
# Building with gmake versions prior to 3.82 fails due to
# bug 'brief description'.
# Check for 'undefine' support as a surrogate for the bug fix.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
On Wed 14 Dec 2022 11:05:10 GMT, David Laight wrote:
> From: Nicolas Schier
> > Sent: 13 December 2022 03:59
> ...
> > > > diff --git a/Makefile b/Makefile
> > > > index 2dda1e9a717a..66dfc5751470 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -11,6 +11,11 @@ NAME = Hurr durr I'ma ninja sloth
> > > > # Comments in this file are targeted only to the developer, do not
> > > > # expect to learn how to build the kernel reading this file.
> > > >
> > > > +# Ensure Make >= 3.82
>
> Wouldn't it be better to say either:
> # Ensure gmake supports 'undefine' (added in 3.82)
> or:
> # Building with gmake versions prior to 3.82 fails due to
> # bug 'brief description'.
> # Check for 'undefine' support as a surrogate for the bug fix.
>
> David
'undefine' is not the only feature that has been introduced in make
3.82 that we use, e.g. 'private' keyword is used in rust/Makefile but
'private' is not checkable via .FEATURES. Checking for 'undefine' in
.FEATURES is kind of a hack to detect make 3.82, but as written
earlier, it prevents doing other explicit version comparison like
$(filter-out 3.80 3.81 3.82 3.99.% $(filter 1.% 2.% 3.*)).
I think $(filter undefine,$(.FEATURES)),) is a sensible compromise.
Kind regards,
Nicolas