Re: WIP: About CMake v2

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.o optimizer/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