On Wed, 2025-07-02 at 00:03 +0200, wrotycz wrote: > Tried to get what the `MAKEFLAGS' is but documentation, not manual is > not very helpful.
I'm not sure what "documentation, not manual" refers to. Maybe you mean the man page? The man page is not intended to describe everything about makefiles etc. It's a short reference page only. The user's manual is the place to go to learn new things about GNU Make and makefiles. > Info is better. I read it and still didn't get that as it seemed > somewhat complex if not convoluted. > So I made a Makefile and this variable is neither simple nor easy, It's not expected that users look at the value of MAKEFLAGS that make itself sets (so, the version generated in a recipe). That format, although documented, is technically internal to make and is used to send options from the parent make to the child makes. You should not try to change it nor do you need to understand its format unless you're trying to do very specific, advanced things. If you want -k always, for example, you just add: export MAKEFLAGS=-k to your environment. That's it. If you want to set GNU Make-only options but still be portable you can use GNUMAKEFLAGS instead (this behavior of MAKEFLAGS is part of the POSIX standard so all variations of make--that adhere to the standard-- will use it). > Speaking of autodetect, with big compilations, like compiler or > binutils or similar, I don't use -j$(nproc), specially - > j$((`nproc`*2)) as too many times it become unresponsive and without > free thead couldn't even be tamed. You can set a different -j on the command line; the new setting overrides the default taken from the MAKEFLAGS environment variable. Also, this is exactly why the -l option was invented. Maybe you'd have better luck with a setting like: export MAKEFLAGS="-j -l$(nproc)" which allows as much parallelism as you can get, limited by the CPU load. As we discussed before, though, the problem may not be CPU at all, but memory. This is especially the case if you don't have a good alignment between CPU and memory; for example you have a system with 24 CPU threads but only 8G RAM or something like that, then you are running memory-hungry programs like big link operations etc. Unfortunately currently make has no concept of RAM limitations and cannot offer any help for these situations, you have to adjust the -j value by hand. > Make's git repo could be helpful - make a branch with the feature and > let it to be tested. This way you can gather useful information from > users and be prepared to easy merge in case it's accepted. The problem for features that impact backward compatibility is that the very people who are most impacted are the ones who would never try such a branch. But in any event before a feature can be tried out it has to be implemented.
