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