[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: version 15e feedback
email@example.com ( Steve Olson ) writes:
> - I see you guys have been working on nicer compile scripts and the like,
> but still are some problems. In particular, the CMU-o-centric pathnames
> embedded in the scripts required hand editing.
Well, originally, those scripts were just so we could compile the
system here. I'll look into generalizing them a bit.
> - Related to the above, ldb/Makefile.boot has a non-standard reference to
> cpp that requires hand-editing. Similarly, ldb/Makefile needs editing on
> account of the location of the X include files. I always found it strange
> that X-specific information is needed in the lisp kernal anyway.
We always build CLX into the system and it's easier to just link the c
code directly into the runtime image than to use load-foreign. Also,
stuff loaded with load-foreign isn't saved when you save a core, so we
would have to keep re-loading the foreign stuff.
> - I am a bit disappointed that there is not more support for the automatic
> generation of the initial ldb/lisp.h. The method suggested by
> William.Lott@cs.cmu.edu a while ago does work, but its a bit painful.
> (Better than the kludge I initialy came up with, though.)
> I don't undertand why you just don't distribute an initial lisp.h for
> each architecture, but I suppose you must have reasons. Should I just
> re-use the lisp.h from a build of a previous version -- will lisp.h
> ever change a lot between versions?
the lisp.h file only changes when the object format changes or some
fundamental feature of the runtime changes. This is indeed rather
rare. So you can just keep using the previous lisp.h. [When you run
Genesis, it tells you if the lisp.h changed, and therefore need to
recompile the C code.]
> -- Steve Olson
> -- MIT Lincoln Laboratory
> -- firstname.lastname@example.org
CMU Common Lisp Group