der Mouse wrote:

> What's broken about it?  If the kernel build would fail for the lack of
> something, that something should be built as necessary.

the chapter you refer to, chap-kernel.html, has a section 28.4 about
"building the kernel manually". you can either follow the instructions
there (which you didn't, since you decided to use build.sh) or refer
to the linked "crosscompiling netbsd with build.sh". the instructions
for using the tool of your choice is in a different chapter.

it is assumed that if you chose the build.sh way (the "non-manual" way)
you would have at least clicked that link too to find out what it takes
to use build.sh.

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

this is 2006. i hope that internet usage has become rather wide that
refering people to online documentation is something we can afford to
do; after all, to use netbsd they had to *download* it from somewhere.

> It is?

yes, unless you really really try to make things hard and complicated.

> The Guide with a section 17.9.3 that suggests using config and make

oh get real. the section 17 about "tuning netbsd"? yes, that's where
a new user would go (not "building the system" :).

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

see, that's your problem. a little higher in that very chapter 28,
like i already mentioned above, there's:

"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,
~~SBuilding the kernel using build.sh~T 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.

however, if you *did* follow the guide, you would also answer to your
previous question that i answered and you didn't quote:

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

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. possible?

> (I'm referring to
> http://www.netbsd.org/guide/en/chap-tuning.html and
> http://www.netbsd.org/guide/en/chap-kernel.html here.)

me too; but i didn't read these selectively.

> Right.  I'm sure that will help immensely.

netbsd receives prs for the smallest things; netbsd receives prs from
people with the most esoteric problems. so far i don't recall, not
in the past year anyway, someone with a desire to change how build.sh
works. :)

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

this is answering based on the assumption that what you said above
about the guide is correct. since it is very far from being correct,
this claim is not valid and my question stands: why would a new user
look at /usr/src? the average new user will look for documentation
*online* (refer to "netbsd wiki", "netbsd blogs", etc.) and not bother
reading over the 700 lines of BUILDING file.

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

> 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.
that said, i also believe that if every new user would do exactly what
you did, and -- and saying that is a risk i'm willing to take -- have
the same attitude as you, then no one would succeed in building netbsd
and the problems you describe would be long solved.

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

this only stresses it more that what you really want is a documentation
fix -- and with that i have no problem.

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

but i already told you this is documented and the guide even you refer
to mentions it!

> Only if they bothered telling us.  I probably wouldn't, if I were new
> to it.

i really believe this is a rather "big" problem if it's impossible to
build netbsd following the documentation given, and we would see at
least one pr about it before yours. this is not the first release with
build.sh.

> I see people wondering why NetBSD has so few users.  If this is the
> welcome they would get 

you do not even deserve a reply for that statement.

> - following instructions, to find out that they
> don't work, and when reporting these problems being told they're idiots

dont lie.

> for not reading the documentation they *did* read and that they got the
> broken instructions from - I think we need wonder no more.

ah, so now its the instructions that are broken and not build.sh. like
my previous mail says: i would okay documentation fixes, but not changes
to build.sh.

also, if you "*did* read" the documentation, how come you never noticed
the overkill note and the -u flag? just asking.

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

heh; even though throughout this mail and previous it is clear that if
anything, the documentation needs updating, you prefer to update 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. 

please let's do that -- that's where the problem is.

> (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; this is
something that might require a code change after some more thought. :)

-e.

-- 
Elad Efrat