>________________________________
>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.
>
Thanks for the reply. I should point out I'm talking specifically about how
include works, not how the rest of the rule processing etc. works. I'd
suggest that the compelling argument for change is that leaf Makefiles are
the things people of various skill levels on the team actually interact with,
and assuming include worked the way I had expected it to work they could
remain fairly vanilla. E.g.:
ifndef TOP
include ../Makefile
else
SUBDIRS = <yadda yadda>
TARGETS = <list of things>
SRCS = <etc etc>
endif
All of the complexity you allude to can be safely buried in the TOP-level
Makefiles, leaving most users blissfully unaware of how the sausage is made.
Another idea I had for a solution is to add yet another directive, possibly
something like:
.include ../Makefile
(dot-include is a mnemonic for "include relative to here").
- Ed
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make