Subject: Re: bin/32573: [dM] build.sh fails gratuitously
To: None <email@example.com, firstname.lastname@example.org, email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 01/19/2006 23:12:29
>> 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.
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
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
> 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 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 firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B