Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!hsdndev!wuarchive!mit-eddie!uw-beaver!zephyr.ens.tek.com!videovax!dougs
From: dougs@videovax.tv.tek.com (Doug Stevens)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Turbo C++
Summary: Make using TCC slower than project-make using TC (longish)
Message-ID: <6232@videovax.tv.tek.com>
Date: 21 Dec 90 20:40:40 GMT
References: <25970@uflorida.cis.ufl.EDU> <2261@abcom.ATT.COM>
Distribution: usa
Organization: Tektronix TV Measurement Systems, Beaverton OR
Lines: 23

In article <2261@abcom.ATT.COM>, mdb@abcom.ATT.COM (5013 ) writes:
> Have you looked at using make to manage your project??
> At one point Borland was distributing a .PRJ to a .MAK which could then
> be used by MAKE.          

I have used both MAKE with TCC and project-make within TC. The project
make appears to be MUCH (much, much ...) faster. I speculate that the main
difference is that when running MAKE, TCC must be re-loaded every time that 
a dependency triggers a compilation, and that TC loads the compiler only once
before checking dependencies and compiling.

I also prefer the project make because I don't have to maintain dependency
lists in the makefile (even with automated tools, such as Polymake, you have
to remember to run the tool to update the dependencies).

I think the original complaint had to do more with changes in a single .h
file triggering compilation in manyh .c files in the system. Changing from
TC to make with TCC is not going to fix this (unless you don't add the
dependencies into the makefile, in which case you can really generate some
confusing problems). My approach is to use lots of .h files, each dealing
with a subsystem within the system being created, instead of a single 
massive .h file; that way, changing a .h only triggers re-compilation in the
files in that subsystem.