> 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,
I can't help but think this is an entirely upside-down approach. You
appear to be expecting context's make-file to supply values for the SRCS
and SUBDIRS of the module, which should surely be the master source for
that information. When sub-module foo is under separate version control
from the rest, this is particularly important: the source list may
change from one release of foo to the next - the parent shouldn't need
to care - that's *why* it includes a make fragment from the sub-module.
The parent should tell the module things like where to stick its
generated files, what compilation options to enable (ideally at an
abstract level, DEBUGSYMS=YES rather than CFLAGS=-g, so that components
can adapt to the language they're actually in), but it shouldn't be the
place for details internal to the module - so that it is, in fact,
modular.
As I described previously, the robust way to do non-recursive make is to
have a config.mk in each component, that says the things that clients of
that component need to know in order to build it, for inclusion by
client make-files. You can optionally have a Makefile in each component
that it makes sense to build "autonomously" - it also includes
config.mk, of course, while setting general options suitable for its
use.
FOOSRC ?= .
FOOGEN ?= $(FOOSRC)/gen
FOOSUB = $(patsubst %,$(FOOSRC)/%,<yadda yadda>)
FOOTGT = $(patsubst %,$(FOOGEN)/%,<list of things>)
FOOFILE = $(patsubst %,$(FOOSRC)/%,<etc etc>)
ifeq (NO/,$(WARNINGS)/$(filter -w,$(LFLAGS)))
LFLAGS += -w
endif # configure lex
MODULES += $(FOOSUB)
TARGETS += $(FOOTGT)
SOURCES += $(FOOFILE)
include $(FOOSUB:%=%/config.mk)
It involves making module-specific details clear - but, if you don't do
that, your make fragment isn't actually useful to the client make-files
anyway, as they need to know your source (and sub-module) lists, which
they shouldn't need to do.
Eddy.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
