Re: Making KCL on SCO

[wfs@nicolas.ma.utexas.edu (Bill Schelter)]

This is a reply to the fairly long comments from ajb, about his
difficulties in porting to SCO unix.


    4) evalmacros.data, cmpspecial.data and move-if-changed
       are filenames bigger that 14 chars, producing an Error.

The 14 character file name limit did not stop things on ATT SysV, ibm
aix2, or hpux all of which have this limitation.  So SCO is clearly
handling something in a different way from normal SYS V.  I agree that
changing the filenames to something < 14 chars would be desirable.
Unfortunately I can think of several software systems which have
hardwired references to init_cmpspecial(),.. [they link one big image
containing all files, so as to have all text read only and shareable].
This necessitates more changes in code outside the akcl distribution,
something which causes more problems.

       - Load compile-lsp and compile-cmp files that compile all the .lsp
	 files slowly (who cares, we only do this once) but does not attempt
	 to load them.
	 A special switch can prevent the appending of the .data files to the

Having a separate utility for loading in all the .lsp files and one
for compiling all these files, is certainly a reasonable idea.  It
does mean duplication of the list of object files which you object to
elsewhere.  You say who cares about how fast this happens: Since I
recompile the system 100's of times I guess I do--wasting my time is
important too.  Still if done correctly, with .o files loaded as
compiled, the whole process would probably be faster on a machine with
sufficient memory, since the compiler would not be running interpreted as
much of the time.  I am thinking further about this.

Also as you note, one needs some utilities from the .lsp files to be there
in order to be able to load the .lsp files.   That is the reason that raw_kcl
uses the 4 basic files defmacro,evalmacros,top, and module.   So the make
must make allowance for such files.

Finally the current method means that when I change a file in the cmpnew
directory and retype make, the whole system recompiles and saves in about
4 minutes on my hp.   This is important to me.

       Fix sys_kcn.  It would not make on the Mips/Ricos where the saved_kcl
       has been successfully made ("No Package Named COMPILER").  KCN

The saved_kcn is used by a number of people [the bug you mentioned about
no package 'compiler is simply adding an autoload for a compiler:: symbol.
this has now been altered, to check if the compiler package exists].

    1) Strange dependacies [sic] on the original KCL, the new system seems to rely
       on files compiled by the old.  This seems to be an attempt to optimise [sic]

The dependencies are explained in the README file.  The original
authors of KCL wished the KCL files to be redistributed verbatim.
This is the reason for the change system used by AKCL.  It does have
the beneficial effect of making the amount of code which must be
redistributed smaller. 

       simply placing "**CHANGED**" markers at appropriate places 
       would be helpful.

The change files in the V directory are nothing other than a complete listing
of all Changed code.   There is also a file c/ChangeLog which contains
summaries [less complete] of changes.

    3) I also note that the gbc seems to sweep the C Stack?  Perhaps
       a list of potentially system dependant behavior like this could be made.
       WARNING - an unpredicatble part of the C Stack \is actually in registers

This code has been very portable.   Of course I worry about what is in registers!
The caller of  mark_stack_carefully puts all the register values into
a buffer on the C stack, so they will be marked [if I don't have setjmp
then I would be in much deeper trouble than this, since it is used throughout
the lisp to handle catch, etc].


	 have an #include.  What do AT&Ts 6,000 Unix
	 programmers actually do?)

Note that some of your problems are definitely related to SCO, since AKCL
compiles without error on ATT System V.   It is SCO's unix which is causing
the problem.   One could wish for a better make, but I would still have to
stick to the intersection of the capabilities of all the different makes.

       add SHELL=/bin/sh everywhere etc.

What about for machines where sh is somewhere else, or where it has a different
name.   I think when you are making the .defs file, you have to examine the 
other .defs files and synthesize what you want.   I definitely should
try to make these better annotated though.    You might have noted that some
of the other system V .defs files had the SHELL=/bin/sh line.

    New features and faster programs are great but for users like myself a
    clean system that one can feel confident about is far more important.

I agree that having things reliable is VERY IMPORTANT.  When you have
a port to a new OS, I think running as many tests as you can get your
hands on is very important.  I always test at least a large number of
nqthm examples as well as compiling maxima and running a large number
of tests there.  One reason I believe that not distributing the .c
files output by the compiler is beneficial, is that this forces people
to run the compiler some before the system is built.  It this does not
succeed then it is better to find it out at this stage than later.  It
does mean that the make requires two passes, and so is a bit more
complicated and less "clean", but I think you should have more confidence
in the result, not less.

Bill Schelter