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. The fact you didn't use make build before and that's effectively
what build.sh is doing today doesn't mean the process changed, just you
were rolling your own before and did things in whatever order you chose.

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.

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

#   build: builds a full release of netbsd in DESTDIR. If BUILD_DONE is
#       set, this is an empty target.
#   release: does a `make build,' and then tars up the DESTDIR files
#       into RELEASEDIR, in release(7) format. (See etc/Makefile for
#       more information on this.)
#   snapshot: a synonym for release.

That's from the 1.5 Makefile (and to be honest a lot of that same verbiage
still exists in today's Makefile).

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

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

Again, nit picking for examples that just don't exist. I compared a 1.5
Makefile against what build.sh does today and I see the same number of passes
and today it's more optmized to not go into areas it doesn't need to for 
certain steps. If anything it's cleaner now than it was before.

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

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

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

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.

James