Greg Stark wrote:
> It is tempting and I've been wanting to evalangize this approach ever
> since read http://aegis.sourceforge.net/auug97.pdf but I've never
> actually had practical experience with it and iirc it's always this
> scenario of wanting to compile submodules multiple times that blocked
> using it.
I actually played with that a bit awhile back, after seeing that paper
referenced the fourth or fifth time (meh). I converted a few of our
current subdir makefiles into "module.mk" files that were included
rather than recursed into; for instance optimizer/util/module.mk would
do this:
+OBJS += optimizer/util/clauses.o optimizer/util/joininfo.o optimizer/util/orclauses.o optimizer/util/pathnode.o
optimizer/util/placeholder.o\
+ optimizer/util/plancat.o optimizer/util/predtest.o optimizer/util/relnode.o optimizer/util/restrictinfo.o
optimizer/util/tlist.ooptimizer/util/var.o
then the backend-level makefile would do this:
+include $(patsubst %,%/module.mk,$(NEWSUBDIRS))
where NEWSUBDIRS were the subdirs I had converted, so
NEWSUBDIRS = access optimizer
In turn, optimizer/module.mk would be this:
NEWSUBDIRS = geqo path plan prep util
include $(patsubst %,optimizer/%/module.mk,$(NEWSUBDIRS))
It seemed to work fine for the small subset that I changed; then I got
lazy and never got around to writing a macro to do the subdir makefile
conversion (and of course I wasn't going to do it by hand). Of course,
some things needs special treatment (postgres.bki, gram.c etc) which I
also never got around to even trying.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
