Date: Wed, 28 Jan 1998 11:20:18 -0700 From: Nate Williams <nate@mt.sri.com> To: shimon@simon-shapiro.org Cc: Nate Williams <nate@mt.sri.com>, John Polstra <jdp@polstra.com>, current@FreeBSD.ORG Subject: Re: gnu/usr.bin/cvs/libdiff Message-ID: <199801281820.LAA05134@mt.sri.com> In-Reply-To: <XFMail.980128092526.shimon@simon-shapiro.org> References: <199801281620.JAA04669@mt.sri.com> <XFMail.980128092526.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801281820.LAA05134>