Hi! Most probably know the subjectalready (and the writings on http://miller.emu.id.au/pmiller/books/rmch/). That is the first version to kill recursive make calls (read: no more `make -C` somewhere somehow): http://bernd.petrovitsch.priv.at/olsr-ng/recursive-make-considered-harmful-v1.patch against http://gredler.at/hg/olsrd as of now (beware it's 70KB or so). What is done/how does it work: - each subdirectory which has now a Makefile (read: src/{cfgparser,olsr_switch}, lib*) gets local.mk containing the build info for that directory. - these local.mk are included in the main Makefile. - these local.mk defines targets, dependencies etc. similar to now. Gains: - the build time on my Via-C3 is roughly halved (using ccache in both cases of course) - we save a dozen fork(2)+exec(2) of the sub-makes, they needn't parse Makefile.inc again, etc. (and the output of a `make build_all` is smaller). - src/cfgparser build is much cleaner and simpler. - make `install_all` is *much* faster since we don't call ldconfig for each plugin but once at the end. The question is more if the ldconfig is necessary - ATM one (at /me does it) can install the plugins anywhere and olsrd finds it withoput LD_LIBRARY_PATH, /etc/ld.so.conf, or similar if the PREFIX and DESTDIR is used correctly (identical to autotools). - I actually regression-tested the new and old dependencies: Just do `make clean_all && make build_all >build-clean 2>&1 && for f in Makefile Makefile.inc */*/local.mk; do touch "$f"; make build_all >build-${f//\//-}" 2>&1"; done` and (tk)diff build-clean against the others. The main difference to the current `make -C` way is IMHO that the subdirectory's name must be present on the .o/.c/.h/.d/... files as the (only) `make` call never chdir(2)s (unless someone adds a `cd` to some target). Other differences: - the MAKEBIN and (presently unused) MAKELIB make variable vanish. The main() function for the cfgparser binary is moved into a separate .c file. That makes life much simpler and easier (and it is quite crufty right now). - since we have one `make` in one directory, no more TOPDIR or similar variables That patch is not final as - all lines with "#dbg" will be removed - these are the old ones. - I intend to/propose to/would simply delete all the now superfluous Makefiles. Otherwise one has to fix them (or keep the duplicated build info). - and a few simplifications more are possible afterwards (but would disturb `hg fetch` right now too much if someone fixes some build issue) And now the real hacky stuff[0] possibly creating the usual porting problem: Since the build for the plugins is pretty identical, we use Makefile magic which reduce the plugins local.mk to one line (not counting comments) which generates variables, targets and dependencies in a way that can use them like normal handcoded Makefiles. If you want to see what really is generated, duplicate the line in a plugins local.mk, replace the "eval" with "error" or"warning" and find the output. lib/httpinfo/local.mk is not so trivial so one can see that that approach doesn't impose any limit. The main question is if that builds on the more obscure[1] non-GNU-systems like OpenBSD or MacOS. I have no idea (and no possibility to try/check) what the `make` there can do or not. The patch should be applicable with `-p1`. If you dare try it (please do!;-), please tell me if it works or not (and where). And for error reports, please attach *all* of the output and mail it or put it somewhere to download. Bernd [0]: There *is* much more in `make` then just variables and dependency rules;-) [1]: Don't take it personal. I just can't think of a better word right now. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services