From owner-freebsd-current Wed Jan 28 10:20:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA16133 for current-outgoing; Wed, 28 Jan 1998 10:20:39 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA16128 for ; Wed, 28 Jan 1998 10:20:33 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA01953; Wed, 28 Jan 1998 11:20:20 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA05134; Wed, 28 Jan 1998 11:20:18 -0700 Date: Wed, 28 Jan 1998 11:20:18 -0700 Message-Id: <199801281820.LAA05134@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: shimon@simon-shapiro.org Cc: Nate Williams , John Polstra , current@FreeBSD.ORG Subject: Re: gnu/usr.bin/cvs/libdiff In-Reply-To: References: <199801281620.JAA04669@mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk > > 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. > > Then either make is broken (by concept, not implementation) or ineffective > unfit for our purpose (Now, this is a revalation :-) No, make knows what it's supposed to do, and does only that. It doesn't try to be all things for all people. > > 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. > > Automated tools CAN be smart enough. Was done at Xerox PARC some 20 years > ago, at TRW about 1984 or so. Few other places. I have done it too around > that time. Unix make cannot, I agree. Right, because Unix make follows the KISS principle. If you want something big and complex, buy something big and complex to build your sources, but they'll require more resources than currently required by BSD-Make. Heck, it might be that by using the big complex systems you'd require as many resources as blowing the entire system away everytime and re-building from scratch. > > 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. > I think you are saddned prematurely. I do understand these things. And I > disagree with the absoluteness of inability to automate. As I said above, > you were already proved wrong a decade or two ago. No, read my last sentence. 'Somewhat effecient'. Those other tools are all but effecient. (At least in terms of what's required by BSD-Make). They require lots of disk/CPU/checking/etc.. resources, which aren't necessary for 99.9% of folks, which is why I'd be that 'make' is still the most common build tool used today. It's not perfect, but it works almost all of the time w/out requiring tons of 'administrative' overhead. > I have to wear a different hat at times; The hat of a manufacturing > engineer, not a design engineer. If you're manufacturing *AND* using FreeBSD-current, then you've got another hat called 'clueless manufacturer', since *NO-ONE* should be using a moving target like -current in any sort of manufacturing environment. If you are, then you deserve to have your legs kicked out from under you every day for being so silly. As a manufaturing process, manually > intervening in make proceedings is not acceptable, as it introduces an > uncontrolled element into the process; Will I (or my less experinced > replacement in the ``factory'') be able to reliably and predictably > reproduce what I am building. This is referred to as manufacturability and > the reason why production cars look so different from show cars. And that's why people who rely on FreeBSD being stable all the time don't track FreeBSD on a daily basis, and do their own 'tracking' process. See above for avoiding kneecap destruction. > My original posting was a simple, un-loaded ``what happened''. And, if you couldn't figure out what happened on your own after using/depending/building FreeBSD for this long, you shouldn't be depending on FreeBSD building, since you don't understand the process. If you play with fire you're gonna get burned, so don't whine about getting your fingers charred when you've been told time and time again that the matches are *really* short. Again, I repeat. If you don't know how the build system works, then either roll your own, figure it out, or don't bother depending on it working and to the 'blow everything away everytime' solution. [ Solutions that aren't solutions deleted. ] Yeah, and you've just proven again that you don't understand *why* the compilers are built like they are. Can you say 'namespace pollution'? I knew you could. Nate