Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!edcastle!cs.ed.ac.uk!cs.edinburgh.ac.uk!nick
From: nick@cs.edinburgh.ac.uk (Nick Rothwell)
Newsgroups: comp.sys.mac.programmer
Subject: Re: A library of compile class functions?
Message-ID: <2477@skye.cs.ed.ac.uk>
Date: 26 Nov 90 12:38:50 GMT
References: <SBCHANIN.90Nov22222153@rice-chex.ai.mit.edu> <RSFINN.90Nov24181333@e40-008-11.mit.edu>
Sender: nnews@cs.ed.ac.uk
Reply-To: nick@lfcs.ed.ac.uk
Organization: Wavetables 'R' Us
Lines: 25

In article <RSFINN.90Nov24181333@e40-008-11.mit.edu>, rsfinn@athena.mit.edu (Russell S. Finn) writes:
> In article <SBCHANIN.90Nov22222153@rice-chex.ai.mit.edu> sbchanin@ai.mit.edu (Steve Chanin) writes:
> Yes, namely the fact that projects and libraries can't contain more
> than 32K of code, which TCL does.  The suggested solution to your
> problem is to create a project containing TCL only, and compile it
> once; when you start a new project, make a copy of that project and
> use it as a starter.

Er... My application project includes three TCL projects (called Core 1,
Core 2 and More). There's also a project with TBUtilities + MacTraps +
other bits and pieces. These TCL projects are shared between all my TCL
applications (well, currently only one...!).

The secret is to have two Core Classes projects (A-M and N-Z perhaps) -
a single one would be too big, as you say.

Doing it your way (if I understand it correctly) has two big disadvantages:
(1) recompiling everything is expensive, and (ii) global find/replace
searches go through the TCL sources as well.

-- 
Nick Rothwell,	Laboratory for Foundations of Computer Science, Edinburgh.
		nick@lfcs.ed.ac.uk    <Atlantic Ocean>!mcsun!ukc!lfcs!nick
~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
 "You ain't seen nothing yet. I can take this floor out too, no trouble."