James Chacon wrote:
> On Tue, Dec 13, 2005 at 03:52:55AM +0100, Johnny Billquist wrote:
> 
>>James Chacon wrote:
>>
>>>On Tue, Dec 13, 2005 at 03:00:07AM +0100, Johnny Billquist wrote:
>>>
>>>>James Chacon wrote:
>>>>
>>>>>On Tue, Dec 13, 2005 at 01:24:58AM +0100, Johnny Billquist wrote:
>>>>>
>>>>>>James Chacon wrote:
>>>>>>
>>>>>>>I'd be interested to pinpoint examples here. I'll almost bet that's the
>>>>>>>compiler getting slower. It's been fairly well documented that as gcc 
>>>>>>>goes
>>>>>>>up in versions the slower it gets.
>>>>>>
>>>>>>Oh. The fact that we now use build.sh, which runs over the same 
>>>>>>directory tree a number of times definitely hurts a lot.
>>>>>
>>>>>Umm..we always did. Make obj always ran before make includes and both
>>>>>scanned the entire tree.
>>>>
>>>>No, we did not.
>>>>I remember when we didn't have a build.sh... :-)
>>>
>>>So do I and I'm reading the Makefile from 1.5.
>>>
>>>It clearly (in make build) does a tree pass of cleandir, a tree pass of 
>>>make obj, includes, builds lib, etc and installs it and then does a 
>>>complete pass again with dependall.
>>
>>I didn't do a make build. I don't remember when make build appeared, but 
>>I don't even think it existed at the time I started using NetBSD.
>>I have actually never used make build myself, as far as I can remember. 
>>I finally switched over to using build.sh around the 1.6 or so.
> 
> Ok, so you always custom built before...You could still do that today if
> you chose.

I don't think you called it "custom build" back in 0.9...

> Nothing stops you from doing all custom builds today. Build.sh didn't add
> any more passes really. It just sums up a lot of the steps now.

I seem to remember that I finally started having problems just doing a 
make build, and that's why I had to change over to build.sh.

>>>>And furthermore, the tools directory is passed through a few extra 
>>>>times, as is gnu/lib and some other places...
>>>
>>>gnu/lib always was.
>>
>>Not for me. But I guess you can understand that from above.
> 
> Yep, I didn't realize we were talking about a world where you did something
> completely custom and now want to complain that the automated stuff does a
> few more steps (but actually does them correctly where-as before if you
> were skipping some of these or the order, you would lose). Even back in
> the 1.5 days the documented way to rebuild everything was this target:

Look. 1.5 is fairly recent in my view. Let's compare back to 1.4 or 1.3 
instead. I can understand why you pick 1.5, because that's when a lot of 
cruft got included, so compared with that, much less have happened (if I 
remember correctly).

And running over gnu/lib several times is still unneccesary, and takes a 
lot of extra time, no matter if it's been done that way for several years.

>>>>>build.sh just calls make in the end....
>>>>
>>>>Yes. A number of times.
>>>
>>>I actually doubt it's more than 1 extra pass in the end and even then most
>>>of the passes are optmized now to not go any deeper than they need to.
>>
>>I admit that this has improved a lot from a year or two ago, when we had 
>>a separate pass for "depend", followed by the "all" targets, and other 
>>extra passes that I've probably forgotten about.
>>But it still is heavy work.
> 
> This is completly false. It never did a depend pass and then an all pass
> from anything I can ever remember. It's always done dependall.

Well, for a while it did. I've always been running on current, so don't 
ask me if it ever were that way in a release, because I've never used a 
final release.

> If it did this, it was a short short period and most likely in error.

Or maybe it was when build.sh was being developed some...

>>>>>>The libcrypto stuff that was included some time ago really added one 
>>>>>>day or two to a build on my 8650.
>>>>>
>>>>>libcrypto added back around 1.5? (or even before). This is like 5 years 
>>>>>ago...
>>>>
>>>>Yes.
>>>
>>>Ok, so you want the system to be what it was in 1995 basically. Just come 
>>>out
>>>and say that then. You clearly claimed in your original email it was "stuff
>>
>>>from the last year", yet all your examples of *bad* stuff are 5+ years old.
>>
>>You must read rather sloppy. Or how did you miss pam and NLS?
> 
> I was referring to your libcrypto reference here. It's fairly obvious
> since we've both included it here....

Sometimes it's really great to have quotes still in place.
You said (and you can see it above): "You clearly claimed in your 
original email it was ''stuff from the last year'', you all your 
examples for *bad* stuff as 5+ years old."

Please stay sharp.

>>>If PR's get open they get fixed in general. Maybe not right away but that's
>>>the only way we know. The hooks aren't put in so they can't be used. 
>>>They're
>>>put in so people can use them. If you chose not to, and then complain about
>>>how you're getting all this stuff you don't want I really don't have an
>>>answer for you...
>>
>>Sigh. So I complain that building takes for ever, and a big reason is 
>>that the system now contains so much more than in the past. You point 
>>out that much can be skipped. I point out that this will result in 
>>build.sh failing.
> 
> Not necessarily. Most of the MKxxx options work to my knowledge. You're 
> claiming *with no factual basis* (since you admitted you haven't tried it)
> that build.sh will fail. I claim otherwise and if they do, file a PR
> and it'll get fixed.

*sigh*
I definitely pointed out that there *were* open PRs to this effect. Yet 
you say that I have no factual basis. Just because I haven't tried it 
don't mean it isn't so. When a PR already have been filed, I don't 
really see that I have to reproduce the problem myself and file yet 
another PR on the same issue.
You know, it's not that difficult for anyone to search the pr database.
Check toolchain/26329 or toolchain/30675.

>>And the answer to that is basically: tough luck. It should work. Wait 
>>for a while, and maybe you can build the system.
>>That's really comforting. So instead of waiting a week or two to have a 
>>new system, I should wait a couple of months or so.
> 
> I never said tough luck, but I did point out that if you're finding bugs
> and want them fixed it comes down to:
> 
> 1. File a PR and wait
> 2. Dig in and fix it yourself 
>    a. file a PR with the fix (almost definitly will get applied)
>    b. post it to the mailing list (maybe it gets noticed and gets applied)
> 3. Do nothing and just complain on the list about how stuff breaks now and it
>    was so much better "back in the day".

And I've been doing 2b most of the time, thank you.

> Obviously today it's "choice 3". Look...I'm not even trying to be an ass about
> this but all your examples so far on "it's so much worse" have been
> about things which changed over 5+ years ago or longer. 
> 
> And yes, vax's/sun3's/etc are slow enough machines that items which add
> 1s of overhead on a modern x86 might add 20s on those boxes. Enough of these
> adding will cause concern, but that's why there are hooks for building a much
> leaner system than the default. But it seems you want both worlds. You want
> the complete system and to have it perform the same as it did in 1995. This
> isn't a static system, it grows and changes over time for various things but
> a good chunk of those have knobs to disable them if you chose.

I just think NetBSD is heading down the wrong road, and I voiced that 
opinion. The reaction:
1. "gcc" is the culprit.
2. You're throwing FUD.
3. You're doing things the wrong way.
4. You're imagining things.

I personally think that NetBSD should try to not have a lot of this 
extra crud in there. Let's figure out ways of having it installed as 
packages instead, if people want it. Keep the core system small.
But like I've said all along. That's just my opinion.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol