From owner-freebsd-current Wed Jan 28 09:27:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA01166 for current-outgoing; Wed, 28 Jan 1998 09:27:23 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA01152 for ; Wed, 28 Jan 1998 09:27:17 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 16609 invoked by uid 1000); 28 Jan 1998 17:25:26 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-011998 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801281620.JAA04669@mt.sri.com> Date: Wed, 28 Jan 1998 09:25:26 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Nate Williams Subject: Re: gnu/usr.bin/cvs/libdiff Cc: John Polstra , current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk On 28-Jan-98 Nate Williams wrote: ... >> 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. Then either make is broken (by concept, not implementation) or ineffective unfit for our purpose (Now, this is a revalation :-) > 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. I know John was helpful and I think I thanked him for it. > 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. 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. I have no problem, as a developer/hacker/hobyist intervening in automated processes. It is part of the fun of it all and an excellent way of learning the internals of many pieces. I have to wear a different hat at times; The hat of a manufacturing engineer, not a design engineer. 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. Let me eemplify this to you in our cointext; While still using Linux, I never raised this type of issues. AS the whole Linux thing is currently totally unmanufacturable as a complete system, it is mute to even discuss this. One of the attractive points of FreeBSD over Linux is the ease of manufacture: CVSup is a fantastic tool that allows simple, automated tracking of the ENTIRE O/S. ``make {build,install}world'' allows rapid verification and upgrade, ``make release'' allowsfor a complete manufacturability of the product. In this context I allow yself to pay attention to these issues. My original posting was a simple, un-loaded ``what happened''. To this I got, as usual, plenty of excellent help very promptly, whiich is great. Does not mean we cannot digress it into a different discussion altogether :-) > 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. Oh, yes. I do. I am not upset, mad or distressed by it at all. It is cheap enough to simply blow it all and re-start. I even thought ``make world'' does it. I know ``make release'' does it for sure. I like this discussion, as I am sure there is a better way of doing it. I just do not know what that better way is. Yet. ... > 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. This is purely ``intelectual'' with no practical value: Forget make for a minute. It is a tool and not a very good one either. Think about the process. What do we have (in a simple, typical case): A product, which depends on subassembleys, which depend on components and configuration data: A Corvette which is assembled of a body, interior, power train and suspension. This is biased by color, interior options, engine selection, tires selection, etc. A FreeBSd CD which is composed of kernel, data, scripts and executables. A kernel which is composed of sources, options and configuration instructions. The question is: How much of this information is intrinsic (assembley instructions) and how much is options. For example, I contend that, for the most part, #include is totally unnecessary. The only reason we #include is so that the compiler can resolve our FILE *foo; statements. Since the compier only knows to sequentially search flat records in a hirerchial database (open explicitly named text files), we need to tell it exactly what to include. If, instead, we could have a complete, seekable and fast database that included all the definitions in /usr/include, you would not need it (for the most part. You would still need the -I/usr/include in the assembley instructions. Carry this concept in your mind for a while and you will discover that you really do not need tools like make at all. Actually BSD .depend files are a step in this direction. A different tool is needed. True. > 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. :) Agree. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313