tools/docheck: fix for non-GNU OSes

[smlng]

Contribution description

This PR provides 2 fixes to run ./dist/tools/doccheck/check.sh on non-GNU (Linux) OSes such as FreeBSD. First it allows to overwrite the make command through the environment, which is needed bc FreeBSD provides non-GNU make by default and thus RIOT must use gmake instead.
And second, there was also an encoding error in generate-changelog.py bc on FreeBSD if no encoding is set for open it defaults to ascii but RIOT uses utf-8.

Testing procedure

Run make static-test or ./dist/tools/doccheck/check.sh on your (favourite) OS and it should still work as usual.

Issues/PRs references

#3392

[smlng]

@cladmi can you have a look on this one please? maybe you have a better way/idea on how to override make with gmake on non-GNU OSes such as FreeBSD? The idea is that the script can be invoked via make static-test but also standalone. Problem is that FreeBSD comes with a non-GNU make which raises errors when used with RIOT Makefiles.

[cladmi]

For the python change, I do not think this is currently a reasonable idea.

Most of the things in RIOT assume that python is executed within an UTF-8 environment.
#11691

The issue you mention here seems like the FreeBSD used for testing, is not configured with an "adequate" locale as open uses the system default one

https://docs.python.org/3/library/functions.html#open

[cladmi]

Also, almost everything tells to call 'make' directly, does it not make sense to ask to have a PATH where 'make' is 'gmake' ?
Changing this is in theory "possible", but not sure it is realistic or worth the effort of adding the indirection globally.

There is of course lots of false positive in this output but you get the idea:

git grep 'make' '**' ':!doc' ':!**/*.c' ':!**/*.h' | wc -l
1065

[smlng]

@cladmi you're right, setting locales to utf-8 stuff fixes that - will drop the 2nd commit, okay?

[smlng]

thx for pointing that out.

[smlng]

regarding your second comment: to me it would make sense to use ${MAKE} in all Makefiles, scripts and so on, to achieve easy reconfiguration of make command.

[cladmi]

So also, documentation, README, examples should mention use 'make' or 'gmake' ?
And packages and external tools compilers updated to use $(MAKE) too if they use it directly.

I don't find it worth the effort for a platform that is not used.
Just ask to configure the system accordingly.

Windows users also have some setup to do anyway.

[smlng]

Just ask to configure the system accordingly.

so you mean by setting an alias?

[smlng]

mhm, makes sense to

[smlng]

closing, thx @cladmi for discussing this. alias make=gmake works for me.

[cladmi]

I did not thought about putting an alias, I tend to have my '~/.bin' in the path where I do "script" aliases, but alias should work perfectly.

[smlng]

I did not thought about putting an alias, I tend to have my '~/.bin' in the path where I do "script" aliases, but alias should work perfectly.

yep, using ~/bin is even better, more versatile and also was the only option to get it work with FreeBSD as a Jenkins Slave.

[cladmi]

was the only option to get it work with FreeBSD as a Jenkins Slave.

When you have a non interactive ssh session, you must manually source the environment with . /etc/profile if you want your environment to be included.
This should work to have the alias defined too.