From: Bruno H. <br...@cl...> - 2003-08-01 11:23:27
|
Sam wrote: > > 1. All modules should use clisp.h, not lispbibl.c. modules.o is part > > of the modules infrastructure; modules.c is recompiled by > > clisp-link. > > if so, why is it needed for base/lisp.run? > > functionally, clisp.h is a subset of lispbibl.c. > changes in clisp.h should not affect base clisp. I see it just the other way around: most changes in lispbibl.c (namely those that are not reflected by clisp.h) should not require a recompilation of modules.o. > the development cycle is > > change module > recompile > repeat The other development cycle is change lispbibl.d recompile base/lisp.run regenerate clisp.h but it hasn't changed don't recompile all the modules relink full/lisp.run repeat > > How to get rid of this NO_CLISP_H ugliness? > > > > - clisp.h depends on unixconf.h; this dependency should be removed > > for the platforms that don't have unixconf.h. Then the $HOS = unix > > test can go away. > > I don't understand it. I meant that makemake.in should generate a "clisp.h : ... [no unixconf.h] ..." dependency line on Amiga, DOS etc. platforms. > But since you mentioned unixconf.h, I wonder if it is possible to > generate unixconf.h.in using autoheader. ... > > CLISP build infrastructure is very complex. I wish it could be > simplified to rely more on standard tools like autoconf. Yes it is possible, by transforming those pieces of unixconf.h that autoheader does not already generate into AH_VERBATIM calls inside the *.m4 files. > > - When cross-compiling, how do you want to create clisp.h ? > > what's cross-compiling? $CROSS = true, in makemake, is set when you compile clisp using a C cross-compiler, e.g. on Linux you generate the Mingw lisp.run. (Of course you cannot generate the memory image this way.) Bruno |