Path: utzoo!censor!geac!jtsv16!uunet!samsung!brutus.cs.uiuc.edu!apple!claris!drc
From: drc@claris.com (Dennis Cohen)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Need a review of THINK C 4.0
Message-ID: <10672@claris.com>
Date: 10 Nov 89 15:41:33 GMT
References: <1346@mrsvr.UUCP> <296@dbase.UUCP> <2127@se-sd.NCR.COM>
Distribution: na
Organization: Claris Corporation, Santa Clara CA
Lines: 24



Okay.  One of my few peeves with the THINK environments seems to be starting
to strike more people now -- that is the project management.  When working
with something like TCL (maybe someday we'll get MacApp or something more
sophisticated and larger) you have a lot of files that need to be compiled
for virtually every project.  Now, the simple (semi)solution is to build a
library and include it which is fine; however, you now lose the ability to
debug into it with the source debuggers.  One of the few things that SADE
did right from a user perspective is say that the debugging info is saved
separately and that I can still use the .sym files in other projects (ThC
terminology).  What it boils down to is that something analogous to subprojects
is necessary when dealing with libraries that are used in multiple development
projects and the subprojects need to keep their attributes -- ie if I include
the TCL project (which contains its object code and debugging info) in my
Art Class project, when I debug the Art Class project I still have access to
the sources and so forth from TCL.  I know, it's a lot of work and could
adversely affect performance (though the time it takes to recompile TCL in
every project makes me disbelieve the latter), but I think it's something
that is needed.

Rich, would you please forward my comments along to Michael as a suggestion
(and to John and David as well for THINK Pascal).  I really think that it is
a workable solution that would greatly benefit the customer base.