Hi hackers!

    For those of you who use the MAKE utility written by Landon Dyer,
there is a new "utility" named PREMAKE.  It takes one argument, which
it will prompt for, which is the name of an included file.  PREMAKE's
function is to search *.MAC files for ".INCLU" (minimum for a .INCLUDE
directive) or ".COPY" and the name of a file which has just been changed
(the included file).  For all .MAC files containing these strings, the
current date is changed to "now" by copying the file on top of itself.
MAKE will sense this as a change, and the next time you MAKE your program,
the files so tagged by PREMAKE will automatically be assembled.

    PREMAKE has limitations.  Because it must physically examine the file
(twice) to check for inclusion, it is not reasonable (in terms of CPU time
and hence operator wait time) to give PREMAKE the name of a file and have
it un-nest all those files in which it is included (every time it found
a match, it would have to start all over again, looking for INCLUDEs or
COPYs for the file it just tagged).  To get around this, PREMAKE spits
out the name of all the files referring to the file recently modifed
(the included file).  It is up to you to realize that some of these files
are NOT highest level files and to do a premake with them, yourself.

    PREMAKE only checks *.MAC; files in the current directory.  This is
cuz your interdependencies are not expected to go outside any specific
directory, and it is annoying to have to type "[]*.MAC;" every time
you wanna use it.  If anyone can justify a reason to make the searched
filespec different, or variable, send mail to this address.

sas

		    This missive is dedicated to (and
		done in) the style of Jeff Boscole, who,
		dedicated or not, was done in, in
		inimicable style. 

    There has been a fair amount of debate about the PREMAKE utility.
I am seriously considering a veterinarian to eliminate the planarians.

    MAKE was originally a UNIX utility, used to conditionally build
programs from their component parts, if (and only if) any one or more
of the parts was newer (more recently changed) than the "target".
Definitionwise, the TARGET is the unit currently being built, and it
DEPENDS on those units (files) which are inputs to the program doing
the build (compiler, assembler or linker).  The target of one step is
quite possibly depended upon in subsequent steps in the build of a
particular program.  This is indeed the case with current workings of
68000 "C" development.  The executable binary is dependent on one or
more object modules, each of which is dependent on one or more assembly
language sources, each of which is dependent on one or more compiler
sources.

    As you can see from the not-quite-nonsense spouted so far, MAKE as
originally conceived is not intuitively obvious in function, when the
details are known.  It is intended to be fed an input file, called a
makefile, which is a list of the dependencies to be resolved, and the
command text neccesary to resolve each.

    There is an infinite number of applications for the Unix version of
MAKE.  It was designed for a system with several potential sources for
a given module, and several layers of dependencies for a specific utility.
I am not prepared to describe nor debate the use or usefullness of MAKE;
I do feel compelled to point out that it is a convenience tool; a simple
command file (in fact, simpler than the corresponding makefile in every case)
can rebuild the desired end module unconditionally.  The primary advantage
of MAKE is in the elimination of CPU time that can be pinpointed as non
essential, and hence user time in waiting for the processes that are not
entirely neccesary.  In our own case, this would reduce the load on the
VAX a tiny bit.

    Landon Dyer's incarnation of MAKE assumed MACxx development, and I
cannot say for certain, but I expect it was MAC65 only.

    There is also a version written in C by Eddie Babcock.  I don't know
a whole lot about it either, but since Landon's was written in DCL, Eddie's
will have the advantage of speed at least, and probably quite a bit of utility
as well.

    The whole purpose of PREMAKE was to allow users of MAKE to cheat.  There
are header files for virtually every sizable project, containing such
information as copyright notices, authorship, identity, and documentation,
which matter not a whit to the execution of the program in which they are
included.  Yet for all the same reasons as these, they must be included in
each and every module at the source level.  Global options, such as debugging
flags, are also included here, to make the unit easier to develop.  Here is
the problem with mixing these non-code items (which are subject to change
due to many sources, legal, managerial, and financial, not to mention
whimsical) and developmental stuff you put there BECAUSE you intend to
change it:  unless the changes will directly affect the function of a
module in which they are included, you don't really want to reassemble (or
whatever) the source unless and until you are ready to release.  There is
no way that the computer can know and/or correlate all of these things.
Look how much fun you had, and you KNOW how the system works!

    So, in order to reduce the time between iterative versions (hackings)
{RE-CURSE:  1) See recurse.  2) What happens when you rehurt yourself.}
you can cheat.  Avoid non-essential compiles / assemblies with MAKE.
Avoid redundant assemblies by eliminating non-code header file dependencies.
When such a header file will cause an effect in the generated code, use
PREMAKE to search for the inclusion directives and renew the date on the
source module, forcing MAKE to recognise the change.

    To reduce the clamor for change in PREMAKE, it has been changed.
PREMAKE is implemented as a DCL command file, and is now used with three
parameters:  the file type of the sources, the required text of the
inclusion directive, and the filespec that has changed, and requires
recompilation.  For the MACXX assemblers, which is assumed to be the
majority case, PREMAKE is defined at login time as:
    PREMAKE :== @SYS$SYSDEVICE:[UTILITIES.COM]PREMAKE .MAC .INCLU
    	... and you use it as $ PREMAKE HEADER or $PREMAKE HEADER.MAC
if HEADER.MAC is the file with the changes.  For C programmers, you
can either redefine PREMAKE or invent you own word as in:
    PREMAKE :== @SYS$SYSDEVICE:[UTILITIES.COM]PREMAKE .C #INCLUDE
    	... and the default extension will be .C;  PREMAKE will search
"*.C;" for #INCLUDE and your filename on the same line.  If your filename
is a .C file, the extension needn't be specified to be recognised.

    Of course, anything costs.  Because of making it general for languages,
the second search was eliminated.  It used to search for .COPY as well as
.INCLU (.INCLU is all you need for .INCLUDE to be recognised), but now it
does only the .INCLU directive.  If you want to search for .COPY, you will
have to define your own word, and do it as well as PREMAKE. It still does
not nest.  PREMAKE still only checks *.MAC; files in the current directory.

    As usual, if you or any of your operatives should get burned, I will
disavow any responsibility for my actions.  Bug reports should be sent to
this address.

sas