Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!haven!purdue!bu-cs!mirror!ima!haddock!suitti
From: suitti@haddock.ima.isc.com (Stephen Uitti)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Make question (was MPW vs Lightspeed)
Message-ID: <11529@haddock.ima.isc.com>
Date: 25 Jan 89 16:31:59 GMT
References: <322@s1.sys.uea.ac.uk> <24218@apple.Apple.COM> <334@s1.sys.uea.ac.uk> <7260@csli.STANFORD.EDU>
Reply-To: suitti@haddock.ima.isc.com (Stephen Uitti)
Organization: Interactive Systems, Boston
Lines: 74

>In article <7260@csli.STANFORD.EDU> nathan%teleos.com@ai.sri.com writes:
>What is the *real* goal of make files?
>...dependencies are based on file dates

There is more than one *real* goal to 'make' files.  Yes.  In UNIX
'make', dependencies are explicitly specified in the Makefile.  There
are shortcut rules, like *.o depends on *.c.  There are also a few
built in dependencies of this sort.

>...why does one ever have to recompile a file that hasn't changed?

A file is recompiled when it or something it depends on has changed.
In UNIX, the ".o" (relocatable object) depends on the ".c", which may
depend on other files, for example ".h" included files.  These may
then depend on other nested include files.  These are often omitted,
since people often don't have dependency generators, or want the
Makefile to work on other systems with different include structures
(SysV vs BSD UNIX or MSDOS).  Also, system include files are thought
not to change.  The final target generally depends on one or more ".o"
files, and one or more libraries.  Often, library dependencies are
omitted, since libraries seldom change, especially system libraries.
Sometimes, a change in the Makefile requires that the project be
recompiled.  Explicit Makefile dependencies are seldom provided.
People who edit the Makefile generally know what needs to be
recompiled.

>...is it just to check parameters, return results, data structures
>and globals variables changes?

Compilers don't do cross checking in this regard.  Either you have the
common things (structures, prototypes, etc.)  defined in commonly
included header files, in which case 'make' will do the right thing
(assuming the header file dependency is set up) or the compiler will
have no way to do any cross checking anyway.

>...can I just just recompile the files that have changed and then relink?

Usually.

>...The savings in turn around time on large applications is significant.

This is one of the points of 'make'.

>...if A depends on B.  B depends on C.  I change C.  A does not depend
>on C.  Do I need to recompile A?

If (for example), A includes B, which includes C, A should depend on
C.  UNIX 'make' does not check for this.

Things that 'make' is used for:
1. Documentation on how to build (& install...) the project.
2. Automation for project building.  Reduces (or magnifies)
   errors and improves speed.
3. Automated optimization (don't recompile everything if
   it can be quickly proven to not be required).
4. Automation for things often only slightly related to
   the project (general scripting).

Lightspeed C on the Mac has a builtin 'make' like system, which they
call the 'project'.  It provides 1, 2 & 3 above.  It is easier than
'make', since it is not a real language, and automatically determines
the dependencies (during compilation).  It is harder to make errors.
LSC has attempted to increase speed and reliability everywhere.
General scripting for other things is hard on the Mac, since unlike
UNIX, there aren't hundreds of utilities that can be run from a script
(though things like macromaker are attempting to change this).  On the
other hand, features of the Mac allow simpler project installation.
In particular, many more systems that need to have file storage can
have it without having more than one file (using resources), and an
application can find out where it was invoked, and where it lives,
allowing it to have other files there to reference, without the need
for imbedded path names, etc.

	Stephen.