🚀 go-pugleaf

(Before I start I want to make it clear that nothing I say is meant
to deride what Beebe has done. This is intended strictly as constructive
critisism.)

I've been playing around trying to get Beebe's drivers working using
Turbo C 2.0. I'm doing this before I start doing what I really have
in mind, which is doing a Hercules driver using Beebe's software.

While playing around I soon learned that Beebe uses "#include"
statements extensively - so extensively that all files needed to
make a driver are seen by the compiler as a result of "#include"s.
In other works to make a driver for the Apple laserwriter you say
(more or less)

	TCC DVIALW.C

and that's all even though 20 or 30 files have to be compiled to
make the driver.

When I first saw this I wondered why separate object files weren't
created for each source file needed by the driver. Beebe's approach
reminded me of Turbo Pascal and some other old Pascal compilers which
didn't permit separate compilation. My objection to this approach
was that it made developing new drivers a very slow process on
old slow XTs, which is what I happen to own.

At first I didn't understand the explaination in Beebe's manual
but Beebe kindly explained it to me. The reason for this is that
various #define's and #ifdefs are used each time a driver is built.
This means that the object code generated when a file is compiled
for one driver may not be the same when the same file is compiled
for another driver. This means that object files can only be
used, in the worst case, for building one driver.

I thought about this for a while and then came up with the following
suggestion for a solution.

My solution involves mainly changes to makefiles, along with the
modifications of the source code to remove the "#include"s that
become superfluous if my idea is implemented. Also added is the
requirement that a directory be created for each driver being
built.

First of all, divide all the files into two groups, those
that contain driver-specific dependencies, and those that don't.
Then, modify the makefile so that the object files produced when
compiling driver-specific files are put in the driver-specific
directory. (Systems that support "make" access to object libraries
should use object libraries). Also modify the makefile so that
the proper files in the proper directory are used in the linking
step. The makefile would of course have to be modified to show
the proper dependencies.

After a driver has been created the first time, remaking the
driver will go much faster because only files that have
changed since the driver was last built have to be compiled.
Then, if an additional driver is to be built, only the
driver-specific files have to be compiled. All the driver-independent
files will already have been built.

There are several minor disadvantages with this approach.
The first is that linking might take longer because there will
be more files to be linked. If object libraries are used
this shouldn't be much of a problem. The seconds is that more
diskspace would be required than in the current method.
The actual amount of extra space would depend on the number
and size of driver-dependent files.

Maybe if I owned a faster PC I wouldn't think this was so
important. As things stand, however, I'd have to think hard
before starting on any driver development projects because
the thought of all that extra compilation time is hard to
stomach.

Am I being too picky? Is this a good idea? Am I overlooking
anything?


Jon Forrest		Lawrence Berkeley Lab., 486-4991
forrest@lbl.gov			(internet)
ucbvax!lbl-csam!ux1!forrest	(uucp)
FORREST@LBL			(bitnet)