> I think changing gmake's behavior to match cpp's will eliminate the
> need for a lot of hacky farting around to get non-recursive systems
> working smoothly.
I can sympathise. The present behaviour effectively requires one to cd
to (or pass a -C for) the directory of a make file in order to make it
work right. Then again, the commands it runs tend to need that cd, too;
and this was likely assumed by your old recursive make files - the
typical recursive rule is
cd $(subdir) && $(MAKE)
not
make -f $(subdir)/Makefile
after all. Effectively, switching from traditional recursive make to
inclusion of fragments into a single global make involves all the
transformations that would be needed to convert recursive make from the
former form to the latter. (Aside from breaking the interesting bits
out of each module's Makefile into a config.mk that it includes, so that
client modules can include the same while the Makefile still retains the
ability to build locally, ignoring the client's larger context.)
The problem for commands is commonly tamed by building inside the source
tree - so the generated files are intermingled with the sources - so
that %.c and %.o (etc.) hide the path to relevant files in their % and
commands see it suitably expanded from $@ and friends; but, even then,
the make-file always needs a "list of source files", so it ends up
needing a variable that means "here" (relative to which to specify
them), which a make -f would need to over-ride on the command-line.
When keeping the source tree pristine, one needs two variables, one for
source tree and one for built tree; rules then make $(out)/%.o depend on
$(src)/%.c and so on.
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.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
