By the same logic, one can use a (module-specific) variable meaning
"here" in each sub-directory's make-file fragments; so foo/config.mk
refers to its source files as $(FOOSRC)/bar.c and so on, rather than
assuming FOOSRC=. (although that likely remains the ?= setting in
foo/Makefile, for use when building just
foo). You can then equally
include $(FOOSRC)/baz/config.mk as long as you first set BAZSRC to
$(FOOSRC)/baz so that it knows where *its* "here" is, and so on. (Of
course, if you have two copies of baz in use by different contexts, it's
going to get weirder; but that was going to be a problem any way you
like to come at it.) For out-of-source building, you also need parallel
FOOOUT and BAZOUT variables, of course. Note that you need these
variables to get the commands and rules right, so I don't really see a
strong case for getting rid of the need for them when including
makefiles.
So, while the include structure in make files is a pain to re-work
during converting from recursive make, it's really just another example
of how you have to re-work the rest of the make-file's content; so I'm
not persuaded that the (tempting) case for making the inclusion easier
is actually
compelling. It wouldn't solve the matching problems for
source lists and command-lines, after all.
Eddy.