Makefile.include: require make version 4.

[jcarrano]

Contribution description

Old versions of GNU Make (especially on OSX) are a pain to deal with. This commit introduces a warning when such an old version is found. The goal is that in the future the warning will be turned into an error. For that I can open a PR, which we don't merge, and is tagged for a future release.

Complying with version 4.x is easy on OSX by using homebrew, and on Linux, even Debian stable has the required version.

Testing procedure

The test PR allows you to see what happens when you have an old version (it sets the version to 5, which does not exist at the moment.) Just go to any example and type make.

If you do the same without the test PR no warning is emitted.

Issues/PRs references

The old version of make in vanilla OSX is blocking the introduction of rules to make directories.
Old make does not support ?= in canned recipes.

[jcarrano]

PLEASE NOTE The version here is 5 just to show what happens if you have an old version, so it can be tested.

Without the test commit, the required version is 4.

[kaspar030]

Old versions of GNU Make (especially on OSX) are a pain to deal with.

Could you elaborate on that?

[jcarrano]

Ideally we would require the same version as in RIOTDOCKER. The reason is that we, build system maintainers, can easily test and develop on RIOTDOCKER, but not on OSX, so each time I have to do a fix on a makefile I have to work blind.

Important changes since make 3.81:

Version 3.82 (full list here)

• The pattern-specific variables and pattern rules are now applied in the shortest stem first order instead of the definition order [...] This produces the usually-desired behavior where more specific patterns are preferred.
• The 'define' make directive now allows a variable assignment operator after the variable name, to allow for simple, conditional, or appending multi-line variable assignment. For us, this will allow greater use of canned-recipes.

Version 4.0 (full list here)

• New command line option: --output-sync (-O) enables grouping of output by target or by recursive make. This is useful during parallel builds to avoid mixing output from different jobs together giving hard-to-understand results.

Also, on one of this versions, a bug was fixed regarding rules ending in /, which is blocking us from fixing BINDIR creation and other stuff, like common build directories.

[jcarrano]

I'm sorry about the triplicate comments, github went bananas.

[jcarrano]

What is the status with this? Mac users, is it tool burdensome to install make 4? (it is a sincere question, I've never used a mac in my life.)

[jcarrano]

What's up with this? Should we merge and then wait for the bug reports to come from Mac users? If I break the build that would surely get people interested.

[smlng]

using Home-brew you get gmake not make by default, to replace system make you'll need to add an export for PATH="/usr/local/opt/make/libexec/gnubin:$PATH" in ~/.profile - but that worked for me

[smlng]

What is the status with this? Mac users, is it tool burdensome to install make 4? (it is a sincere question, I've never used a mac in my life.)

using Home-Brew or MacPorts, which most developers do anyway, its straight forward and easy. But still we should have proper versions checks and warnings. for (all) tools we use and require. So this PR makes perfect sense to me for now - because ideally such dependency checks should be done in a system discovery (or bootstrap) step before the compile step; like ./configure ...

As we do not have that (yet), we should proceed with this PR.

[jcarrano]

@smlng

to replace system make....

Is it necessary to replace system make?

But still we should have proper versions checks and warnings

Agreed, except checking for the make version is a special case because:

• Make can self-check (i.e. no need to run external commands which is slow and the reason why we would want a separate step)
• Make is the tool supposed to do the checking (or at least invoke it) so if the check for make is in a script which gets invoked by make it is already too late.

[smlng]

@smlng

to replace system make....

Is it necessary to replace system make?

No, actually not - just prepend to PATH to find the newer version first

But still we should have proper versions checks and warnings

Agreed, except checking for the make version is a special case because:

• Make can self-check (i.e. no need to run external commands which is slow and the reason why we would want a separate step)
• Make is the tool supposed to do the checking (or at least invoke it) so if the check for make is in a script which gets invoked by make it is already too late.

yeah, what I meant was more like: not do the check over and over again but rather have something like ./configure to search for all tools and toolchains once on a system and store that permanently.

[jcarrano]

No, actually not - just prepend to PATH to find the newer version first

Ok, I was asking because I have no idea about MacOS and your comment made me worry that the required setup was too invasive.

...but rather have something like ./configure to search....

yeah, yeah, I know. You cannot even imagine how often that topic comes up in conversations with @cladmi . Removing exports (WIP) should make the situation more tolerable, but it is not a full solution.

Anyways, I'm wandering off topic. Is everybody cool with this change?

[cladmi]

I would like to update the phrasing on the error message. Could you put it as a deprecation warning somehow with a expiry date ? (== 2 releases)

As currently, we do not rely on stem target specific variables with multiple definitions, and no directories targets is currently in. We are thinking about the last one but could be done with */. with a documentation until then.

For the canned recipes, using instead the default-flash-recipe and flash-recipe ?= $(default-flash-recipe) is I think a better alternative as it gives a name that can be used to the default behavior.

I did not know --output-sync was only added in 3.8.2 though…

[jcarrano]

Could you put it as a deprecation warning somehow with a expiry date ? (== 2 releases)

Sure. It is also a good opportunity to start using deprecation warnings (and thus set a precedent).

[jcarrano]

I changed the message, see if you like it. In the meantime I disabled the CI to save a bit of CO2.

[smlng]

lets move this forward: (re)tested on MacOS as described before using GNU make installed via HomeBrew. ACK!

From my side: please squash and drop test commit.

[jcarrano]

@smlng done. sorry for the delay.