Subject: Re: top-level Makefile
To: matthew green <mrg@eterna.com.au>
From: Todd Vierling <tv@wasabisystems.com>
List: tech-toolchain
Date: 10/20/2001 23:21:34
On Sun, 21 Oct 2001, matthew green wrote:
: a couple of months ago i split the mega `build' target up into a bunch
: of smaller targets. the point of this was so that it was really easy
: to restart a build at any one of them... it was addressing a PR as
: well as a N year issue i and many others i've talked to have had.
: do-lib-csu
: do-lib
: do-gnu-lib
: do-dependall
: having these as separate steps was *REALLY* useful. please put it back.
: you can still use the make .for logic, just give them all first class
: targets...
In general, "make build" should be *opaque*, to give a self-contained point
of entry into building the whole system. However, I understand the need to
have some restart points[*] available when the build breaks, and I left
"do-build" as a way to redo a broken build phase: it deliberately starts at
a reliable restart point (the former "do-lib-csu"), and continues through
building the whole tree.
I haven't removed any flexibility in building, per se. You can still do all
those phases individually--simply cd to the appropriate directory and "make
dependall && make install". My intent in src/Makefile was to reduce the
complexity, particularly for people who aren't well ingrained into the build
magic and don't have the time to understand it all.
[*] It's possible that a variable such as ${RESTARTAT} could be used in
src/Makefile, to indicate a point in "make build" where real actions
should begin. This would allow "make build" to become fully opaque,
without causing problems of complexity. Would this be an amenable
alternative?
--
-- Todd Vierling <tv@wasabisystems.com> * Wasabi NetBSD: Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/