The following reply was made to PR bin/32573; it has been noted by GNATS.

From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: gnats-bugs@netbsd.org, apb@netbsd.org, netbsd-bugs@netbsd.org
Cc: Elad Efrat <elad@netbsd.org>
Subject: Re: bin/32573: [dM] build.sh fails gratuitously
Date: Thu, 19 Jan 2006 23:12:29 -0500 (EST)

 >> Right.  That's why I think the manual step of creating /usr/obj, and
 >> the necessity for doing "tools", are broken: it should Just Work
 >> when run naively.
 > i hope that it will not be changed to "just work" in a broken manner
 > of building tools when you tell it to build a kernel.
 
 What's broken about it?  If the kernel build would fail for the lack of
 something, that something should be built as necessary.
 
 >> Where is this guide, and why would a new user, looking at /usr/src,
 >> know to look there?  BUILDING does not contain the word "guide" at
 >> all, and I certainly didn't *see* any reference to such a thing.
 > the "new users" i know would go first to the netbsd website,
 
 Oh, so in order to successfully build a kernel on my newly-installed
 box, I have to have a Web client - and a real-time connection to the
 net - to find out how?
 
 Am I really the only one who considers this utterly ridiculous?
 
 > and click either "documentation and faqs" or "the netbsd guide" on
 > the left. from there it's easy to see that you first need to build
 > the tools.
 
 It is?
 
 The Guide with a section 17.9.3 that suggests using config and make
 directly, not build.sh?  With a section 28.5 headed "Building the
 kernel using build.sh" that mentions neither creating /usr/obj nor
 telling build.sh to do "tools"?  (I'm referring to
 http://www.netbsd.org/guide/en/chap-tuning.html and
 http://www.netbsd.org/guide/en/chap-kernel.html here.)
 
 Right.  I'm sure that will help immensely.
 
 > why would a new user even get to looking at /usr/src?
 
 Maybe because the instructions found by looking at the Guide don't
 work?  Nah, you're right, the new user would probably not bother.
 Becoming a NetBSD *ex*-user instead is likelier.
 
 > speaking of BUILDING file; did you look at the REQUIREMENTS section?
 
 Yes.  It says there is a subtree, tools, which contains tools.  It does
 not say that I need to explicitly build the tools before other build
 attempts will work.
 
 > can you explain to me, please, how a new user would stumble upon the
 > issues you describe?
 
 The same way I did, maybe?  By trying it and getting errors?
 
 > the very first hit for "building netbsd" in google will lead you to
 > "crosscompiling netbsd with build.sh"; the first part of that section
 > describes building the crosscompiler.
 
 I wasn't crosscompiling; I don't see why I should have to even *look*
 at the crosscompiling section.
 
 >> When I repeated the command and saw it rebuilding everything all
 >> over again, my opinion would *really* tank;
 > but that is what you told it to do.
 
 And that is what I think is wrong: in order to make it work at all, I
 had to tell it to do something that is extremely wasteful of resources
 when done the same way the *second* time I try to build a kernel.
 
 >> if I were on a slow machine, where rebuilding those things takes a
 >> significant amount of time, I'd probably write it off as broken and
 >> switch to something else.
 > and then we'd have tons of PRs from people saying it's broken.
 
 Only if they bothered telling us.  I probably wouldn't, if I were new
 to it.
 
 > but we don't. so maybe what you did is not what any other person, new
 > or not, would do.
 
 *shrug*
 
 I see people wondering why NetBSD has so few users.  If this is the
 welcome they would get - following instructions, to find out that they
 don't work, and when reporting these problems being told they're idiots
 for not reading the documentation they *did* read and that they got the
 broken instructions from - I think we need wonder no more.
 
 > reading the documentation for tools you use before using them also
 > has its benefits.
 
 Documentation like BUILDING?
 
 Documentation like the Guide webpage, even?
 
 Documentation like that is what that led me to try, well, to try
 exactly what I *did* try, and got errors from.
 
 > please let's close this PR and not change anything in how build.sh
 > works; but that's just *my* opinion.
 
 Then I'm glad apb, rather than you, is dealing with the PR.  I strongly
 believe *something* needs to change here.  I'd prefer it were the code,
 but it would be an acceptable second-best if the documentation changes
 instead, to make it clear what needs to be done to make a build attempt
 actually work.  (Of course, that still leaves you rebuilding groff and
 makeinfo and pax when all you want is a kernel, something that would
 border on intolerable on a slow port like mac68k...there's a reason I
 call it second-best.)
 
 /~\ The ASCII				der Mouse
 \ / Ribbon Campaign
  X  Against HTML	       mouse@rodents.montreal.qc.ca
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B