Customizing
Think C and Symantec C++
with Frontier
Dave Winer
UserLand Software
Introduction
Think
C is a wonderful development environment. Lots of commercial and in-house
developers use Think C because of its incredibly fast builds, integrated
project management and text editing features. ItÕs a very rationally designed
system, it works, and itÕs well supported. But itÕs always been one major
missing feature ÐÐ there was no way to automate it. So there was a major
penalty for organizing your work as reusable libraries of solved problems ÐÐ
when you made a change to one of your base libraries, you had to manually
rebuild all projects that depend on it.
When
we heard that Think C and Symantec C++ 6.0 would support scripting, we got very
excited. We wanted to see how using scripts to drive Think Project Manager, or
TPM, would impact our development work.
We
learned that there are two types of scripts: ones that add features to TPM that
everyone can use, and customizations that streamline work for individual
programmers and development teams.
For
scripts that everyone can use, check out the Scripting Starter Kit for Think C.
You can download it from any of UserLandÕs on-line services, listed in the last
section.
This
article is a case study in customization. It takes you thru the development
process of a single script, starting with a first proof-of-concept version, all
the way to a very useful and complete script that saves us time every day.
Background:
The Iowa Plug-Ins folder
At
UserLand, we have a set of Think C projects that share a common .h and .c file.
They all live in the same folder:

There
are two Frontier desktop scripts; one that rebuilds all the projects, producing
code resource files, and another that installs the code resources in the System
Folder. ioa.c and ioa.h are the common files used in all the projects. When
these files change, all the projects must be rebuilt.
Looking
inside one of the sub-folders:

Each
sub-folder has a common set of files: a project file, a C source file, a
Resorcerer resource file and a code resource file produced by building the
project.
In
the following four sections we develop the script, starting with a basic
script, then enhance it to include error checking, and then producing a final
version that maintains a log of the compilations it does.
Version
1 -- The basic script
HereÕs
the first version of the buildIOAs script, viewed in a Frontier script editing
window:

The
script loops over all files contained in the folder it was launched from.
system.deskscripts.path contains the full path to the script file. It uses that
path to determine which files itÕs supposed to operate on.
Two
locals are set up: f is the loop parameter of the fileloop, folder contains the
full path to the folder that contains the desktop script. Each time thru the
loop, f contains the full path to one of the files contained within the folder.
FrontierÕs fileloop construct takes an optional value determining the number of
levels to traverse. We ask it to go infinitely deep, so we get to look at all
files contained in all sub-folder levels.
The
script displays the name of each file in Frontier's main window. It only
operates on files that are Think C project files, whose creator id is 'KAHL'
and file type is 'PROJ'.
For
each project file the script calculates the name of the output file:
local (outputfile = (f -
".¹") + ".IOA")
The
variable outputfile is created locally to the script. f is a string containing
the full path to the project file. The .¹ extension is subtracted, using string
artithmetic, and then .IOA extension is added. If fÕs value is ÒSystem:Iowa
Plug-Ins:Checkbox:checkbox.¹Ó the value of outputfile would be ÒSystem:Iowa
Plug-Ins:Checkbox:checkbox.IOAÓ.
We
check to see if the output file exists; if it does, it is deleted. If the build
failed due to a syntax error, we wonÕt be left with an incompatible code file.
The script then opens the project, dirties all changed files, recompiles the
dirtied files, creates the output file and closes the project. These Frontier
verbs work exactly as their interactive counterparts work. But they take
variables as parameters, and as weÕll see in the next version of this script,
they can return error values.
Version
2 -- Add error checking
The
first version of the script was useful, but what if one of the projects didnÕt
compile because of a syntax error, linker error, or if we ran out of disk
space? We wouldnÕt be totally out of luck, because the script deleted each
output file before building it. Even so, we could be left with an inconsistent
setup if we werenÕt watching the script run. And of course, thatÕs one of the
major benefits of using a script to do the dirty detail work for you. You can
read the paper, return a phone call or play with your dog while the script is
running.
So,
in the second version of the buildIOAs script, we add some rudimentary error
checking, so at least the script will stop running and leave an error message
explaining why it stopped. In the next version, weÕll make the script even
better.
HereÕs
the second version of the buildIOAs script:
local (f, folder = file.folderFromPath
(system.deskscripts.path))
fileloop (f in folder, infinity)
msg
(file.fileFromPath (f))
if
think.isProjectFile (f)
local (outputfile = (f - ".¹") +
".IOA")
if file.exists (outputfile)
file.delete (outputfile)
think.openProject (f)
if not think.make (think.makeOptions.useDisk)
scriptError ("think.make failed on " +
file.fileFromPath (f))
if not think.buildProject (outputfile)
scriptError ("think.buildProject failed on " +
file.fileFromPath (f))
think.closeProject (true) Çclose and compact
Several
things have changed in this version. First, we changed:
if (file.type (f) == 'PROJ') and
(file.creator (f) == 'KAHL')
to:
if think.isProjectFile (f)
This
takes advantage of a standard verb that makes it easier to determine if a file
is a project file. Scripts that work with Think C seem to do this a lot, so we
made it simpler to do.
We
also check the returned value of each of the verbs where errors are important:
if not think.make (think.makeOptions.useDisk)
scriptError
("think.make failed on " + file.fileFromPath (f))
if not think.buildProject (outputfile)
scriptError
("think.buildProject failed on " + file.fileFromPath (f))
If
thereÕs a syntax error in checkbox.c, the Error Info window opens in Frontier:

Since
the script is terminated by the scriptError call, Think C will be left pointing
to the error when you come back from playing with the dog. If you click on the
Go To button, the script editor opens the line that called scriptError, with
FrontierÕs debugger active.
Version
3 -- Maintain an audit trail
It
would be nice if the script did as much work as possible, reporting any errors
in a list window, and then moving on to the next project.
WeÕll
keep that list in a Frontier outline window. Every time the script runs, it
adds a major headline to the outline:
Building all IOA projects on 4/28/93;
12:43:29 PM
And
for every build it attempts, the script will report the result:
colorpopup.¹: clean build
When
itÕs done, not only will we know which projects built and which ones didnÕt,
but weÕll also accumulate a record of all the builds done. HereÕs what the log
outline looks like after the first run:
Building all IOA projects on 4/28/93; 12:43:29 PM
button.¹:
clean build
checkbox.¹:
make failed
colorpopup.¹:
clean build
edittext.¹:
clean build
formula.¹:
clean build
frame.¹:
clean build
icon.¹:
clean build
picture.¹:
clean build
popup.¹:
clean build
radio.¹:
clean build
rect.¹:
clean build
static.¹:
clean build
HereÕs
what version 3 of the script looks like:
local (log = @think.log)
local (dir = right)
on startLog (headline)
if
not defined (log^) Çthe outline isnÕt there, create it
new (outlineType, log)
editmenu.setFont ("geneva")
editmenu.setFontSize (9)
edit
(log) Çopen the log in a window
target.set
(log) Çall outline verbs apply to this window
op.firstSummit
() Çmove to the first line in the outline
op.go
(down, infinity) Çmove to the last top-level line in the outline
op.insert
(headline, down)
on addToLog (subhead)
msg
(subhead) Çdisplay string in Frontier's main window
op.insert
(subhead, dir) Çinsert it in the outline
dir =
down
on closeLog ()
target.clear
()
local (f, folder = file.folderFromPath
(system.deskscripts.path))
startLog ("Building all IOA projects on " +
clock.now ())
fileloop (f in folder, infinity)
msg
(file.fileFromPath (f))
if
think.isProjectFile (f)
local (outputfile = (f - ".¹") +
".IOA", result)
if file.exists (outputfile)
file.delete (outputfile)
think.openProject (f)
if think.make (think.makeOptions.useDisk)
if think.buildProject (outputfile)
result = "clean build"
else
result = "build failed"
else
result = "make failed"
addToLog (file.fileFromPath (f) + ": " + result)
think.closeProject (true) Çclose and compact
closeLog ()
Several
new techniques are being used in this version. It adds two new locals to
support the log outline, and defines three local subroutines, startLog,
addToLog and closeLog. In Frontier, as in Pascal, scripts can have local
subroutines, nested to any level that makes sense to the programmer. startLog
creates a new log outline if one doesnÕt exist, and opens it in a window. It
adds the main headline for this script. addToLog adds a new headline
subordinate to the main headline. closeLog does whatever cleaning up is
necessary (for this version not much cleaning up is needed).
Calls
to startLog, addToLog and closeLog have been added in the main body of the
script.
By
the way, this script is much easier to read in Frontier's script editor because
you can collapse and expand headings to see as much or as little detail as you
like.
Version
4 -- Factor the script
HereÕs
the final version of the script:
local (f, folder = file.folderFromPath
(system.deskscripts.path))
think.notebook.start ("Building all IOA projects on
" + clock.now ())
fileloop (f in folder, infinity)
msg
(file.fileFromPath (f))
if
think.isProjectFile (f)
local (outputfile = (f - ".¹") +
".IOA", result)
if file.exists (outputfile)
file.delete (outputfile)
think.openProject (f)
if think.make (think.makeOptions.useDisk)
if think.buildProject (outputfile)
result = "clean build"
else
result = "build failed"
else
result = "make failed"
think.notebook.add (file.fileFromPath (f) + ": "
+ result)
think.closeProject (true) Çclose and compact
think.notebook.close ()
WeÕve
made the script a lot simpler this time by moving most of the code for
maintaining the log outline into a sub-table of the Think table, called
Think.notebook. Of course this makes the script simpler, but it also makes it
possible to use the notebook scripts from other Think C-related scripts.
ThatÕs
it! There may be other improvements we could make to the script, but there has
to be a time to stop and this is it. Having invested about an hour in creating
thIs script, we reap the benefit every time the header file changes and all the
plug-ins need to be rebuilt. In the first week, we recouped much more than the
hour we invested. Plus, the cost to make a change is much smaller, so we make
more changes. The result is more powerful, more reliable and easier to use
software.
Finally,
if you have any questions, comments or suggestions, please get in touch through
one of UserLandÕs on-line services. If youÕre an AppleLink user, check out the
UserLand Discussion Board under the Third Parties icon. On CompuServe, visit
the UserLand Forum in the Computing Support section, or enter GO USERLAND at
any ! prompt. On America On-Line, enter the keyword USERLAND.