> ... remove all those .EXPORT_ALL_VARIABLES: settings. This is just a very bad idea.
Sorry for the side-track but in my experience exporting *any* make variable is a bad idea. Where I work we maintain a "Make Bible" which says something to the effect that the only time it makes sense to export a make variable is if it's not _really_ a make variable. In other words this may be ok:
export PATH := $(PATH):/some/bin
Because $PATH isn't fundamentally a make variable, just a normal environment variable we can manipulate in make syntax, but there's no excuse for ever exporting a make variable that isn't originally an env var. There are only two cases:
1. You want to pass it to a non-make process invoked from a recipe. This falls into the exception above: it's not primarily a make variable or it wouldn't be useful to the non-make process.
2. You want to pass it to a recursively-invoked make. In this case it's far better to do so explicitly:
$(MAKE) FOO=bar ...
Both because it's more self-documenting and because it narrows the scope. FOO will end up in the environment anyway since make automatically exports command line overrides but only in that branch of the process tree.
An environment variable is the logical equivalent of a global variable in C and suffers from all the same issues. Once you've exported a variable you've lost control over who comes to depend on it so it becomes exponentially harder to clean up the environment later. A good programmer limits the number of global variables and no competent programmer would make everything global. Same with the environment.
I understand these capabilities must be provided for POSIX and backward compatibility but I think they should be deprecated. I might go so far as to say so in the manual.
David