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:
> >>
> >>>On Sat, Dec 10, 2005 at 05:48:53PM -0500, Dave McGuire wrote:
> >>>
> >>>>On Dec 10, 2005, at 5:36 PM, Johnny Billquist wrote:
> >>>>
> >>>>>I suspect before long, the VAX won't even be supported any more. It's 
> >>>>>been several years since you last could run build.sh from start to 
> >>>>>finish on a native build on a VAX. And all the new stuff they keep 
> >>>>>adding just means it's getting slower and slower, for almost no return 
> >>>>>(in my view). Building on a VAX 8650 now takes over a week for just 
> >>>>>/usr/src.
> >>>
> >>>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.

> And furthermore, the tools directory is passed through a few extra 
> times, as is gnu/lib and some other places...

gnu/lib always was.

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


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

> 
> >>And libc is just getting bigger and bigger.
> >
> >I'll concede this. In 5 years it's gained abour 50% in overall size.
> 
> Thank you. And speed wise this really hurts. Just processing the 
> makefile for libc takes a huge amount of time.
> 
> >>pam added yet another 12 hours or so. And pam I could really live 
> >>without. NLS support is another of these things that really drags things 
> >>down more, and that I'm not interested in either.
> >
> >You can chose to not compile these in as well if you're compiling yourself.
> 
> Probably true, but it seems as if it's getting more and more difficult 
> to build and maintain the system if/when you decide to change what parts 
> you want in.
> I'm not even sure everything would work if you decided to skip some 
> subsystems.
> I've seen several reports of build.sh failing to do the work if you skip 
> different parts. In fact, there are open PRs to that effect now, if you 
> look.
> So in real life it's not much of an option. :-(

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

> 
> >>This is all my personal views of course, but they are all things that 
> >>makes a build much slower, and you can't just blame it all on gcc. Yes, 
> >>gcc is slower, but the fact is that all the cruft that NetBSD has 
> >>nowadays is much worse for adding time than gcc is.
> >
> >I see most of your statements as FUD honestly. A majority you highlighted
> >were things that have been there for a long long time. Yes, things take 
> >longer
> >but you're also using a machine that hasn't exactly been known to be speedy
> >for a long long time either. I honestly view this along the same lines as
> >people wondering why native compiles on their sun2/sun3 take forever. It
> >never was fast, so *anything* adding to it will appear worse and it's only
> >magnified when you're using hardware that was last current in 1989.
> 
> You may take it anyway you want to. The basic fact is that building on a 
> VAX, any VAX, is becoming so slow it's not doable soon. No matter if you 
> call it FUD or not.

Got a modern example of anything that slowed it down significantly? Something
in the last year+? Again...all your examples come down to "in the good old
days of 4.4lite it was great!".

> 
> And building the whole 4.3BSD took about half a day. Have we really 
> gotten that much improvements to motivate a build time increasing from 
> 12 hours to 7 days?
> Don't even bother answering. I suspect you'll just call it more FUD 
> anyway. The basic fact remains, NetBSD will soon not be usable on 
> systems older than a few years because it requires too much processing 
> power to do just a build, because it contains everything. So I stand by 
> my original claim, I believe the VAX will soon not be supported anymore, 
> since it's just too slow for the demands of the new versions of NetBSD.

Really? It's not usable or just can't be easily natively compiled? I've
yet to hear anything claiming it's becoming unusably slow.

> 
> Anyone remember the complaint about VMS? That it contained everything, 
> and that was a major reason for bloat... Well, VMS is starting to feel 
> pretty slim nowadays...
> 
> >(and yes, I own a bunch of this stuff too...I just don't torture myself
> >by compiling native all that much. I know it'll take weeks).
> 
> And so you don't even know that it won't build natively. Do you even try 
> to boot the systems with new versions?

Occasionally yes. I own almost one of every arch/machine we support so I
can do this.

> 
> >>Actually, just building the tools will take me almost 24 hours.
> >>
> >>>Otherwise vax has built from build.sh (cross mind you since I don't often
> >>>build native) on every release we've ever done in recent memory and will
> >>>on 3.0 as well. Just because it's broke on -current "right now" doesn't
> >>>equate to "over a year"...
> >>
> >>I know. And that is the problem. There is a bug in the gcc/VAX, which 
> >>you don't see when you do cross compiles. I'm telling you (and I have 
> >>said it in the past). A native build on a VAX have not worked for years, 
> >>and that is literally years. Probably close to five by now.
> >
> >Is there a PR for this?
> 
> Don't know. I thorugh there was, but searching now I can't find any. 
> There should probably be several:
> One about build.sh not runnable. People reported it on this list several 
> years ago, and I atleast told them that they could rerun the build 
> several times until they got past the problem.

not runnable? I don't understand here. If builds crash people should file
PR's. Thats the only way things will get fixed long term.

James