Re: modules.o & clisp.h

[Sam S. <sd...@gn...>]

> * In message <200...@cl...>
> * On the subject of "Re: modules.o & clisp.h"
> * Sent on Fri, 1 Aug 2003 13:21:16 +0200
> * Honorable Bruno Haible <br...@cl...> writes:
>
> 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.

1. recompilation of modules.o is cheap (compared to recompilation of
   lisp.run+lispinit.mem)

2. modules.o depends on clisp.h which depends on genclisph which
   depends on lispbibl.c, so you will need to recompile modules anyway.

> > 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

recompiling modules is peanuts compared to recompiling
lisp.run+lispinit.mem.

if you change constsym.d, you must recompile the modules anyway.

if you are working on base, don't do "make" or "make full", do "make
base". 

> > > 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.

is there a platform on which CLISP works but autoconf does not?
I doubt that.

> > 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.

what are those pieces?!

autoheader produces a lot of crap like

autoheader: missing template: RETREADLINKTYPE
autoheader: missing template: RETRWTYPE
autoheader: missing template: RETSHMATTYPE
autoheader: missing template: RETSIGTYPE
autoheader: missing template: RETSTRLENTYPE
autoheader: missing template: RETVFORKTYPE
autoheader: missing template: RET_INET_ADDR_TYPE
autoheader: missing template: RLIMIT_RESOURCE_T
autoheader: missing template: RMDIR_CONST
autoheader: missing template: RUSAGE_WHO_T
autoheader: missing template: RW_BUF_T
autoheader: missing template: RW_SIZE_T
autoheader: missing template: SELECT_CONST
autoheader: missing template: SELECT_SET_T
autoheader: missing template: SELECT_WIDTH_T

one has to go through all the m4/*.m4 files and add 3rd arg to
AC_DEFINE.

are these files used by any other project?
maybe someone has already done the work?
if not, this should be propagated to those other projects.

> > >   - 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.)

has anyone done this ever? how long ago?

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
The software said it requires Windows 3.1 or better, so I installed Linux.