Subject: Re: bin/32573: [dM] fails gratuitously
To: None <,,,>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: netbsd-bugs
Date: 01/20/2006 04:50:02
The following reply was made to PR bin/32573; it has been noted by GNATS.

From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: Elad Efrat <>
Subject: Re: bin/32573: [dM] 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  With a section 28.5 headed "Building the
 kernel using" that mentions neither creating /usr/obj nor
 telling to do "tools"?  (I'm referring to and 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"; 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.
 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
 > 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
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B