Date: Wed, 28 Jan 1998 09:25:26 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Nate Williams <nate@mt.sri.com> Cc: John Polstra <jdp@polstra.com>, current@FreeBSD.ORG Subject: Re: gnu/usr.bin/cvs/libdiff Message-ID: <XFMail.980128092526.shimon@simon-shapiro.org> In-Reply-To: <199801281620.JAA04669@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <foo.h> is totally
unnecessary. The only reason we #include <stdio.h> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980128092526.shimon>