Path: utzoo!mnetor!uunet!husc6!mit-eddie!killer!gtmvax!dave
From: dave@gtmvax.UUCP (Dave Hanna)
Newsgroups: comp.sys.amiga
Subject: Re: Feeping Creaturism
Message-ID: <114@gtmvax.UUCP>
Date: 5 Mar 88 13:02:52 GMT
References: <655@nuchat.UUCP> <657@sandino.quintus.UUCP> <367@sas.UUCP>
Organization: GTE Telemessager, Inc., Dallas
Lines: 34
Summary: Make is not incremental compile!

In article <367@sas.UUCP>, bts@sas.UUCP (Brian T. Schellenberger) writes:
> [it has been suggested that incremental compiles share information
> so only the changes stuff need be re-compiled]
> 
> I do this all the time on Unix and other non-integrated environments.
> It's called  *make*.  You keep your individual files sizes small and
> presto--incremental compiles of only the parts that need to be re-compiled.
> -- 

While I am a great fan of *make*, and use it extensively, I think you're
kidding yourself if you think you can achieve incremental compilation
with it in an application of significant size.  It is incremental
only at the file level, not at the information level.  The application
I'm on at work has 12 subsystems inter-related, the largest of which
has 66 .c files, all appropriately decomposed for functional cohesiveness.
Each .c file has an accompanying .h file, many of which #include
other .h file.  I may change a single #define or enum typedef in one 
of the .h files, but make is going to recompile every file that includes
that .h, directly or indirectly, whether the particular information that
I have changed is relevant in that file or not.  (A re-make of this project
may take 2+ hrs. on a VAX-8200 -- but that's okay - it used to take 12+
on our 68000-based UniSoft machines!)

You would have to interpret "small" (referring to file sizes) as 
meaning "containing a single piece of information"  in order for 
make to substitute for an incremental compiler.

All of which should not be interpreted as meaning I am against make
and in favor of incremental compilers.  I suspect we would have to
give up too much flexibility and/or efficiency in an incremental
compiler, and I like make just the way it is.  I just think we
should be clear about what we're talking about.

	Dave Hanna