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
Cc: Elad Efrat <elad@netbsd.org>
Subject: Re: bin/32573: [dM] build.sh fails gratuitously
Date: Fri, 20 Jan 2006 10:25:10 -0500 (EST)

 >> The Guide with a section 17.9.3 that suggests using config and make
 > the section 17 about "tuning netbsd"?  yes, that's where a new user
 > would go (not "building the system" :).
 
 I mentioned it because it was the first thing I found, going through
 http://www.netbsd.org/guide/en/ serially, looking for anything
 kernel-build-ish.
 
 > "These steps can either be performed manually, or using the build.sh
 > command that was introduced in section Chapter 27, Crosscompiling
 > NetBSD with build.sh.  This section will give instructions on how to
 > build a native kernel using manual steps, the following section
 > Section 28.5, [`]Building the kernel using build.sh['] describes how
 > to use build.sh to do the same."
 
 > if it is not clear that you should follow the chapter 27 link to
 > figure out how build.sh works, then what you want is a documentation
 > fix.
 
 If it is (and stays) necessary to read the crosscompiling chapter to
 figure out how to use build.sh correctly when *not* crosscompiling,
 then yes, the documentation needs fixing.
 
 If it is necessary to read the webpage at all to figure out how to use
 build.sh correctly, there needs to be a clear reference to the webpage
 in BUILDING - and, preferably, in the comments at the top of build.sh
 itself, though that's less important in the presence of BUILDING.
 
 > "This will perform the same steps as above, with one small
 > difference: before compiling, all old object files will be removed,
 > to start with a fresh build. This is usually overkill, and it's fine
 > to keep the old file and only rebuild the ones whose dependencies
 > have changed.  To do this, add the -u option to build.sh:"
 
 Right.  In this respect, the documentation accurately describes the
 behaviour.  I just hold that the behaviour is broken.  Determining what
 needs rebuilding and rebuilding just that is what make is all about;
 pushing that task off onto a human (ie, deciding whether to use -u or
 not) is a step backwards.
 
 If -u is acceptable on the first build (I haven't tried it), there is
 still a problem, in that the optimal behaviour for most cases (which I
 believe is probably people rebuilding with changed config files but
 unchanged source) should be the no-flags-given behaviour.
 
 > which is why i think you skipped documentation entirely and was just
 > pissed off that suddenly things are not done the 1.4/1.5 way.
 
 If that were the case, I'd be ranting about build.sh's mere presence.
 But I've long since stopped expecting modern NetBSD to be pleasant to
 use; I'm running 3.0 for work, where I do a number of things I wouldn't
 put up with at home.
 
 I already knew build.sh existed and was the New World Order.  It's not
 the change of procedure that's annoying me (well, it does annoy me, but
 it's not what I'm kvetching about here); it's that the new procedure is
 broken.  In, of course, my opinion.
 
 >> 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.
 > again, so what you want is a documentation fix, not change to the
 > actual build.sh.
 
 When the reality and the documentation disagree, at least one of them
 needs to change, but nothing says it has to be the doc.
 
 In this case, you are wrong about what I want; I want build.sh to
 change, because I believe a build.sh that works as currently documented
 would be significantly better than correct documentation of the way
 build.sh currently works.
 
 And as I mentioend upthread, fixing the documentation would be an
 accemptable second best to me.  Distinctly _second_ best, for the
 various reasons I also mentioned upthread, but if we have to ship (what
 I consider) broken software, the least we can do is warn its users
 about it, describe how to get it to work despite its flaws.
 
 >> The same way I did, maybe?  By trying it and getting errors?
 > i believe you have way far more experience than any new netbsd user.
 
 Right.  That's another reason why I consider it important to fix this
 (one way or another); if *I* have trouble, a newbie is going to have
 even more trouble.
 
 If other Unix experience is an active detriment when it comes to using
 NetBSD, we have even more problems....
 
 >> I wasn't crosscompiling; I don't see why I should have to even
 >> *look* at the crosscompiling section.
 > because, as quoted above from the very chapter you refer to only a
 > bit higher than the place you were looking at -- build.sh is the
 > "non-manual" way of building netbsd.
 
 How does that mean I suddenly have to care about something in a chapter
 on cross-compiling, when I know perfectly well I'm not cross-compiling?
 
 Again, either the code or the documentation really needs to change
 here.
 
 > this only stresses it more that what you really want is a
 > documentation fix -- and with that i have no problem.
 
 This is the third time you have asserted things about what I want, and
 the second time you are very wrong in so asserting.
 
 When the documentation and the code disagree, (at least) one of them
 needs to change.  Nothing says it must be the documentation.
 
 > also, if you "*did* read" the documentation, how come you never
 > noticed the overkill note and the -u flag?  just asking.
 
 My previous Unix experience, which is not used to having to do make's
 job for it.
 
 > heh; even though throughout this mail and previous it is clear that
 > if anything, the documentation needs updating, you prefer to update
 > the code.
 
 Yes, because I believe the current behaviour is broken in more ways
 than just disagreeing with its documentation.
 
 >> (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.)
 > that is a different problem than the one described in the pr;
 
 Well, yes and no.  It's not the main point of the PR, but the last two
 and a half lines of the PR's text do mention it:
 
 >Fix:
 	Dunno.  As a workaround, I created /usr/obj manually and told
 	build.sh to do "tools" (which, in passing, is extremely
 	wasteful, as it builds a lot of junk - slow-to-buid junk - that
 	is totally unnecessary for building a kernel).
 
 /~\ 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