As it is an RFC, I put remarks here as I find it better than inline.

I like the idea and thought about it already. Having the "target" name in the variable is make way to provide namespaces.
Also, it goes into a way more declarative format and can force solving currently unclear things, even more when applied to dependencies.
I just did not find time to start a migration and enough attention to review, so good that there is interest.

One technical thing, not sure if good or bad, the separator . is not part of a valid environment variable identifier which prevent these variables to be exported.
Which means, that if, currently, it would be used to define private module cflags for example, it could not because of the multi-level recursive makefiles.
One good thing, it would drive to remove the multi-level recursion and use them in target specific variables.
This would allow moving more declarations to the main Makefile.include and so have all the information to not even go in a module directory if it is up to date.
So good in the long term.

For the implementation detail, I am not in favor of the magic part with the foreach

$(foreach var,$(MODULE_VARS),$(eval $(call collect_var,$(var))))

as it hides where a variable is defined and is harder to grep for all things changing a variable.

One technical thing, not sure if good or bad, the separator . is not part of a valid environment variable identifier which prevent these variables to be exported.

Good point. My first reaction is "good".

For the implementation detail, I am not in favor of the magic part with the foreach

What would you propose?

For the implementation detail, I am not in favor of the magic part with the foreach

What would you propose?

Be explicit with CFLAGS += $(call add_module_specific_variables,CFLAGS)

I would then easily find all things defining CFLAGS with only grep.
And the variable could also be defined at different places in the parsing if needed.

One thing I just think about, some definitions may not be suitable to be set like this when the definition order matters. Not blocking or anything just need to be documented that they should work with any definition order.

Be explicit with CFLAGS += $(call add_module_specific_variables,CFLAGS)

Pro's and cons. That would lead to:

CFLAGS += $(call add_module_specific_variables,CFLAGS)
LINKFLAGS += $(call add_module_specific_variables,LINKFLAGS)
CXXFLAGS += $(call add_module_specific_variables,CXXFLAGS)
ASMFLAGS += $(call add_module_specific_variables,ASMFLAGS)
INCLUDES += $(call add_module_specific_variables,INCLUDES)
USEMODULE_INCLUDES += $(call add_module_specific_variables,USEMODULE_INCLUDES)
...

... with probably a growing number. It would also remove the possibility to add variables from within other files, but have them collected at a defined point.

I would then easily find all things defining CFLAGS with only grep.

Same with using a helper, you'd find CFLAGS mentioned as being added to MODULE_VARS.

Wouldn't it be simpler (and more modular) if modules had their CFLAG modifications, etc in their own Makefile.include, which would then be included only if the module is included?

To expand on this idea: instead of having a foreach that does eval, one has a "include" and a foreach to get the paths of the Makefiles.include to include. The eval thing is self-modifying code (the include maybe too, but in a more controllable and debuggable way.)

It's good to know about this, but I withdraw the request for review for me, since I don't have much to say on this issue.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.