Date: Wed, 28 Jan 1998 09:20:48 -0700 From: Nate Williams <nate@mt.sri.com> To: shimon@simon-shapiro.org Cc: John Polstra <jdp@polstra.com>, current@FreeBSD.ORG Subject: Re: gnu/usr.bin/cvs/libdiff Message-ID: <199801281620.JAA04669@mt.sri.com> In-Reply-To: <XFMail.980128003514.shimon@simon-shapiro.org> References: <199801280255.SAA28113@austin.polstra.com> <XFMail.980128003514.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> ===> gnu/usr.bin/cvs/libdiff > >> make: don't know how to make diff.c. Stop > >> *** Error code 2 > > > > It's because you have stale dependencies in your ".depend" file. Of > > course your "rm -rf /usr/obj" fixed that. But you could have fixed > > it a lot more quickly by just deleting the offending ".depend" file. > > When make(1) was born the intent was to allow a programmer to specify the > relationships between various software modules, and the steps needed to > satisfy these relationships. This is typically done in the form of > dependancies; ``To produce /usr/bin/vi, you need vi.o, and libc.a and this > dependancy is satisfied with ld -this -that. vi.o is dependant on vi.c and > stdio.c, and the dependancy is satisfied by eunning cc -something -and > -something_else''. Now, once these rules are specified, one step up to the > directory, type ``make'' and have their favorite complex product built just > right. And make continues to do that. But, if vi.c is removed and broken into vi1.c and vi2.c, and your .depend file says that it needs to build vi.o in order to build (cause your .depend file is from before the breakup), then it knows it needs vi.c in order to build, so it's doing the right thing. Automated tools *can't* be smart enough to know that you completely changed all your dependencies, and John was trying to be helpful and point out that it doesn't require blowing away the world. The *really* sad thing is that somehow you fail to understand how an automated tool can fail and require human intervention, and this is *really* scarey. *NO* (none, zero, zip, nada) automated build tool is completely idiot proof *AND* somewhat effecient. If you want idiot proof, then blow away everything *everytime* (sources, temporary stuff, .o, .depend, .c, .h) re-newfs your files system, and *most* of the time it will work. But, that's alot of (un-necessary) work. But, if you understand how make works (in particular BSD-Make), then you can also understand why some of it's optimizations don't work when the rug is pulled out from under it. > Somewhere along the line, we lost it. I am being told (NOT picking on you > John! :-) that if I remove this (unnamed) .depend file, then all will be > well. That's because you told it to build this (unnamed) .depend file when you built the tree. My point in this posting the original message was not to get the > build going, or get it going in the least amount of time, but to point out > that the automated, self contained dependenciies definition is broken. And will be when the build systems had the tree change so radically. It can't be both effecient *AND* get everything right all the time. You must sacrifice one for the other, and because building is a much more common step than doing dependencies (and dependencies change less often), then it makes sense to do the 'engineering solution' and optimize the common case. Other solution could make the build complete everytime, but it would require re-building files even though they don't need rebuilding, and that is much less acceptable than having to blow away .depend files occassionally. In short, if you're going to run -current, then understand the build system so that you can figure these sorts of problems out on your own, since cockpit error appears to be a pretty common problem, and we'd like the pilot to learn how to pull out of stalls on his own. :) Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801281620.JAA04669>