Date: Wed, 28 Jan 1998 00:35:14 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: John Polstra <jdp@polstra.com> Cc: current@FreeBSD.ORG Subject: Re: gnu/usr.bin/cvs/libdiff Message-ID: <XFMail.980128003514.shimon@simon-shapiro.org> In-Reply-To: <199801280255.SAA28113@austin.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28-Jan-98 John Polstra wrote: > In article <XFMail.980126211210.shimon@simon-shapiro.org>, > Simon Shapiro <shimon@simon-shapiro.org> wrote: > >> While I know most of my shortcomings (thanx for the rminder :-), I still >> did >> nothing short of cvs update (or checkout - matters not), followed be >> make >> buildworld and poof - the compile failed. I read the man pages for make >> several times but do not see anywhere mentioned that I am supposed to >> know >> anything. It implies that what compiled yesterday should compile today. >> >> In othert words, here is the tail output of make buildworld of this >> afternoon: >> >> echo libcvs.so..: >> `LIBRARY_PATH=/usr/obj/usr/src/3.0/src/tmp/usr/lib:/usr/obj/usr/src/3.0/s >> rc/ >> tmp/usr/lib cc -nostdinc -shared -Wl,-f ` >> .depend >> ===> 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. Thanx for the explanation. But I think I managed to make myself musch less than clear again; 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. 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. 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. Were it not broken, the compilation would have succeeded (assuming the source code is not broken (which it was not). It is similar to other postings I tend to aggravate you with to the fact that ``this failed'' and that failed''. As I have no way of causing these minor bugs to be corrected, it is second most efficient to just alert us all to the failure. I have volunteered before to take charge of many of these but this was politely declined (my favorites is silly warnings in the kernel compiles. I routinely sweep these up but looking up each developer/commiter to their uninitialized variables, is quite frankly too time consuming. Much easier to just do it. > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "Self-knowledge is always bad news." -- John Barth ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980128003514.shimon>