On Wed, 31 Oct 2001, matthew green wrote:

:    Well, the intent is to do away with UPDATING entirely when everything is
:    switched to the new toolchain.  The top-level location of this document is
:    rather important, as it is *the* documentation for the entrypoint into
:    building NetBSD from source.
:
: hmm, UPDATING will still be useful for building kernels.

The intent is to do away with UPDATING entirely ... and that includes for
any purposes UPDATING existed.  This implies documenting things like
building kernels, where needed.

:    I'm not entirely sure how confusing it would be to move BUILDING.* and
:    UPDATING into a path such as src/doc, but I know that moving them to
:    src/share/doc is out of the question.  This document has to be somewhere in
:    close reach of the top level Makefile and build.sh.
:
: i guess i mostly object to having multiple (generated!) versions
: of the same file in the top level, as well as other documents.
: a single document is fine.

The .mdoc isn't fine on its own, as a cross-build system won't necessarily
be able to format it into human-readable text.  It's a starting point for
the whole NetBSD build system, even from a completely fresh tree on a
non-NetBSD build host; thus we need to have some preformatted version
available for reading, as we have with UPDATING.

Now, while I did add the plaintext one, it's not very easy to read, since it
cannot be formatted with the "more"-style enriched text.  That's why I chose
plaintext and HTML preformatted versions for checking in.  (Note that you
could also personally generate PostScript and "more"-style text like the
release notes do, but I did not check in such things.)

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/