Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!ncar!tank!uxc!deimos!rutgers!mit-eddie!killer!texbell!sw1e!uucibg From: uucibg@sw1e.UUCP (3929] Brian Gilstrap) Newsgroups: comp.sys.mac.programmer Subject: Re: Make question (was MPW vs Lightspeed) Message-ID: <1220@sw1e.UUCP> Date: 25 Jan 89 13:45:10 GMT References: <322@s1.sys.uea.ac.uk> <24218@apple.Apple.COM> <334@s1.sys.uea.ac.uk> <7260@csli.STANFORD.EDU> Reply-To: uucibg@sw1e.UUCP ([5-3929] Brian Gilstrap) Organization: Southwestern Bell Telephone Co. Lines: 71 In article <7260@csli.STANFORD.EDU> nathan%teleos.com@ai.sri.com writes: >This is a rather naive question but here goes. What is the *real* >goal of make files. > > [deleted to save bandwidth] > >........ Now my question is why does one ever have to recompile a >file that hasn't changed? Is it just to check that the functions >defined in the changed file need the same parameters and return the >same results, and that data structures and globals variables haven't >changed or is it more profound? If not then if the only changes I Well, in languages like C, there are added subtleties such as macros, which aren't really code but do affect the final code. But in general, the primary goal *is* to check these things you mention. >changed or is it more profound? If not then if the only changes I >make are to the body of an existing function or procedure, or adding >new functions/data types, can I just just recompile the files that have >changed and then relink? I've tried this and it seems to work, but If you do it correctly, yes. But this means knowing for *sure* that none of the changes/additions that you made will affect the other files that you don't recompile. >changed and then relink? I've tried this and it seems to work, but >I'm still a bit leery of hidden gotchas. The savings in turn around >time on large applications seems quite significant. It is a definite time savings. However, the dangers of forgetting a dependency and putting out a (more than usually :-) unstable program/system is a serious risk. > A second question: Is it ever necessary to compile a file >that only depends on files that haven't changed? That is A depends >on B. B depends on C. I change C. A does not depend on C. Do I >need to recompile A? If A *truly* doesn't depend upon C, then you don't need to recompile A. However, I would expect that all the routines in B ought to be related (otherwise why would you put them in the same file?....I know, general misc. routines all in one file is an exception but...) So, if all the routines in B are related, and they depend upon C, then the behavior of any given routine in B is quite likely dependant upon the behavior of things in C. Since A's behavior may change if B's behavior changes, and B's behavior may change if C's behavior changes, that means that A really does depend upon C in many cases. Note that languages like C and configuration managers like Make don't work well together. This is because Make doesn't allow you to specify the nature of dependencies with any granularity. It does the simple thing: modification time. There are some other, more sophisiticated programs, such as 'cake' (see comp.sources.unix) which allows you more control over dependencies. Is it just me or does it seem that configuration management slides down the slippery slope toward CASE kinds of tools that will help you figure out if the semantics of your system is correct? as well as the syntax. > Thanks in advance, > Nathan Wilson > Teleos Research > nathan%teleos.com@ai.sri.com I'm sure I've forgotten something, so whoever catches it please follow-up. Brian R. Gilstrap Southwestern Bell Telephone One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg (314) 235-3929 #include