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




