What exactly is the harm in putting back the 3 other targets? These are
specially done before the real dependall occurs anyways and it's quite
useful to have them when you're testing something and want to rerun that
part of the build in place only.

Quite honestly this Makefile isn't that complex..(People getting lost in
the system .mk ones is a different story). If you don't semi-understand
the build process, then yes just fall back on make build and the vars as
described at the top. But...If one knows what one is doing having the 
flexibility to have those pieces all at the top level is very convenient.

Basically I hear good reasons these should have been there and why they should
go back. If the goal was to reduce the overall complexity, sure..clean out
the old cruft (like domestic) that just doesn't make sense anymore. But if
the goal is that normally this file is opqaue then leaving in the convenience
rules has no negative consequences for the average builder whatsoever.

James


ones>
>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/
>
>
>
>
>