- INSTRUCTIONS FOR BUILDING MACINTOSH C-KERMIT FROM SOURCE -

F. da Cruz, Columbia University Center for Computing Activities, July 1985


This blurb explains how to get from the C source files to the final .hqx
file.  The files ckc*.[ch] come directly from the most current C-Kermit
source.  The remaining source files all have names starting with ckm...
Currently, Mac Kermit can only be built on a Unix system under the Stanford
University Medical Center SUMACC Cross-Development System.  At Columbia,
this is done on a 4.2bsd VAX-11/750; it is not known if the same results
will be achieved with SUMACC on other systems.

Here's how to build Mac Kermit from the source:

 1. Make a directory for Macintosh Kermit and cd to it.

 2. Collect all the ckc*.[ch] and ckm* files together into the directory.

 3. Make any desired edits to the ckm*.[ch] source files.

 4. The procedure for changing resources (dialog boxes, etc) is too
    complicated to explain; it involves using the resource editor on the
    Mac to get things looking right, decompiling the result on the Mac,
    and editing the changes back into the master copy on the VAX.

 5. If you are producing a new version of Mac Kermit, either because you've
    edited the Macintosh-specific portions (ckm*), or because changes were
    made to the system-independent portions (ckc*), you should edit ckmker.rc 
    to change the version number.  (Note, don't change the 0.8 part, only the
    edit number in parens; if you change the 0.8 part, the settings files
    will no longer work because of version skew.)

 6. Rename ckmker.mak to makefile if necessary, and then "make".

 7. Use Kermit to send the resulting .rsrc file to the Mac.  If you put the
    following commands into a file called k, then "kermit < k" will do the
    trick:

	 set file type binary
	 send ckmker.rsrc newker.rsrc
	 statistics
	 exit

    Click "Receive" on Mac Kermit's File menu; Mac Kermit will receive the
    file into the resource fork, in binary mode, by default because of the
    .rsrc filetype. 

 8. On the Mac, run SetFile, open "newker", set the creator to KERM, turn on
    the bundle bit and push the "set it" button.  The Mac Kermit icon should
    appear when you exit from SetFile.

 9. Test newker thoroughly, both on normal systems (DEC-20's, VAXes, etc),
    and on IBM's, both through the 3705 (line mode) and the Series/1 (full
    screen).  Transfer both text and binary files with each system.
    Once you've deterimined that the new version works, change its name to
    "CKMKER 0.8(33)" (but use the new version number from step 5).

10. Run BinHex Version 4 on the new Kermit.  Call the resulting file
    CKMKER.HQX.

11. Use the new Kermit to send ckmker.hqx to another system, and then bring
    it back under another name, run BinHex on it to convert it back to an
    application and make sure it still works.  For good measure, try this in
    binary mode on the resource file too.

12. When the program has been built successfully, record your changes in
    ckmker.upd and ckmker.bwr.

13. Put the new ckm*.{upd,bwr,hqx} files, plus any modified ckm*.[ch] source
    files, into the Kermit distribution area(s).  Put the resource file in
    the Kermit-Binaries area.

All of the above applies also to the ckmkey program, with the appropriate
names changed in the expected way.

HINT (may not still be current -- this problem was reported to the SUMACC
people some time ago and could be fixed in the current SUMACC release):

    SUMACC rmaker only allows 50 resources types per compile, our ckmker.rc
    file has passed that limit so if you need to run rmaker, recompile with
    NRESCOMP = 100 or so.

When building Mac Kermit distribution disks, they should contain executable
(and compatible) CKMKER and CKMKEY programs, sample settings files for
normal and IBM mainframe operation, documentation -- CKMKER.{DOC,BWR,UPD},
and the utilities SetFile, BinHex V4, and perhaps Disk Utility, and the
Desk Accessory Mockwrite (for reading the documentation).