Russ Allbery writes:
> Furthermore, with a fixed Makefile, how do you intend to optionally
> include or exclude portions of a build tree from the build?
You can't. A Makefile specifies a list of source files for each target
file. The make program reads these lists and rebuilds any targets that
may be out of date. It doesn't understand that the lists in turn might
depend on other variable sources, such as your build-selection option.
The usual workaround is a manual two-step configure-and-build process,
first creating Makefile from whatever source files, then running make.
Unfortunately, if the sources of Makefile are changed, the user has to
run the first step again, then recreate every target; the make program
still has no idea how the targets depend on the Makefile source files.
My project-management tools eliminate this problem by using a top-down
build strategy with what one might call ``just-in-time dependencies'';
but it will take some work to clean these tools up for widespread use.
Fortunately, static Makefiles are adequate for all the qmail packages.
> scripting switches to configure is a hell of a lot easier than
> keeping and automatically applying patches to a bunch of conf-* files.
How so? It seems to me that ``echo /opt/foo > conf-home;make'' is just
as easy as ``./configure --prefix=/opt/foo;make''. What's the problem?
> Also note that Dan is reinventing parts of autoconf in his build process;
Well, actually, autoconf is reinventing ideas that were popularized by
the sysconf tool in my yabbawhap package in comp.sources.unix in early
1991. But don't allow the historical facts to cloud your judgment. :-)
---Dan
