Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions.

[John Jorgensen]

Looking at the build messages closely, I noticed that the compile of pcl
wasn't completing. The problem was that I was using the raw
unixport/saved_gcl as my "LISP" instead of bin/gcl. The attached patch
takes care of this problem. It also patches gcl/pcl/impl/gcl/makefile.gcl
(instead of gcl/pcl/makefile.gcl) because apparently, on my system
patching gets rid of the symlink and creates a new file.

Use this patch instead of the original patch in my previous
instructions...

As a side note, on linux x86, clcs takes up about 300k and pcl takes up
about 4 meg in the final binary.

J*

On Thu, 6 Jun 2002, John Jorgensen wrote:

> Or we could have a configure option "--with-clos" or something. I haven't
> learned enough about the build system to offer a patch though...
> 
> Another option would be (maybe with their permission) to use the clos and
> conditions from another project (ecls for instance).
> 
> J*
> ---------
> > Greetings!  First, thanks all for the contributions!  I will commit
> > this as soon as we get it into a rudimentary state.  Also would like
> > feedback on its implications on image size, especially as it may
> > affect maxima.  Should we have pcl .o files, separate from the main
> > image, like tkl.o?
> > 
> > "Vadim V. Zhytnikov" <address@hidden> writes:
> > 
> > > John Jorgensen wrote:
> > > 
> > > > I have managed to inelegantly incorporate clcs (in the gcl source tree),
> > > > and pcl-gcl (found at;
> > > > http://www.ma.utexas.edu/users/wfs/pub/gcl/pcl-gcl-2.1.tgz) into a
> > > > "unified" build. In case anyone is interested, here are the 
> > > > instructions;
> > > >
> > > > 1) Check out gcl from CVS. These instructions may work with the release,
> > > >    but I haven't tested it.
> > > > 2) Get pcl-gcl-2.1 at the link listed above and untar it into the gcl
> > > >    tree.
> > > > 3) In the GCL tree, either "mv pcl-gcl-2.1 pcl" or make a soft link.
> > > > 4) In gcl/pcl, run "ln -s impl/gcl/makefile.gcl makefile"
> > > > 5) From the parent of the gcl source root, apply the attached patch 
> > > > with;
> > > >    "patch -p0 <pcl-clcs-gcl.patch". This modifies some makefiles to do
> > > >    the build.
> > > > 5) From the gcl source root, follow the normal build process.
> > > >
> > > > run;
> > > >
> > > > $ bin/gcl
> > > > >(list-all-packages)
> > > >
> > > > to look for the presence of the new packages. I've only done a little
> > > > testing on this build, but it's promising.
> > > >
> > > > Now I realize that the attached patch is the picture of ugliness, but it
> > > > gets the job done. Is there any chance that at least the pcl-gcl package
> > > > could get put into the CVS tree so that folks don't have to search for
> > > > it? After that, maybe someone can clean up my small patch and submit it 
> > > > to
> > > > the maintainer...
> > 
> > I'll try to go over the patch and commit equivalent soon.  Is pcl-2.1
> > the latest?
> > 
> > > >
> > > > BTW camm, thanks for maintaining this easy to build and fast CLISP.
> > > >
> > 
> > Glad its useful for you and hopefully others!
> > 
> > > > J*
> > > >
> > > >
> > > 
> > > That is fine and I also confirms that PCL and CLCS (CONDITIONS) can
> > > be easily compiled, loaded and resulting big GCL image saved.
> > > But having PCL and CONDITIONS in the GCL image file is not enough.
> > > External symbols of these packages must be _present_ in LISP (or rather
> > > COMMON-LISP) and USER (COMMON-LISP-USER) package.
> > > The following script should loosely do the trick. We create COMMON-LISP
> > > package, import in it all required symbols from LISP, PCL and CONDITIONS
> > > and make all these symbols (export) external in COMMON-LISP.
> > 
> > Vadim, do you have a suggestion for where this should go?  Assuming we
> > save everything in the image, init_gcl.lisp?
> > 
> > > List clcs_shadow is borrowed rom clcs. The lisp_unexport list is taken
> > > from lsp/stdlisp.lsp. These are the symbols which should not be present
> > > in the resulting COMMON-LISP package.  Unfortunately these list seems
> > > to be incomplete and resulting COMMON-LISP package still have some
> > > extra unwanted symbols. But at present this is not a great problem
> > > since the first thing which ansi-test verifies is the COMMON-LISP
> > > contents.  It will tell us which symbols are missing and which ones are
> > > superfluous.
> > > 
> > 
> > Wonderful!
> > 
> > > BTW, notice that notorious INT in lisp_unexport.
> > > Actually this is is the right way to do with it. At first I've tried to 
> > > track
> > > down
> > > its origin and purpose but I failed (not surprisingly that C-code has too 
> > > many
> > > INT).
> > > But we just we do not care vary much.  We just do not want to import it in
> > > COMMON-LISP.
> > > 
> > 
> > I too have tried and failed to find the symbol definition.  A todo for
> > any would-be helper.  Can one entirely eliminate unwanted symbols in
> > lisp via this export/inport functionality?  Then it truly might not
> > matter. 
> > 
> > > -------------------------------------------------------------------------------
> > > 
> > > (setq clcs_shadow
> > >  '(CONDITIONS::BREAK
> > >    CONDITIONS::ERROR
> > >    CONDITIONS::CERROR
> > >    CONDITIONS::WARN
> > >    CONDITIONS::CHECK-TYPE
> > >    CONDITIONS::ASSERT
> > >    CONDITIONS::ETYPECASE
> > >    CONDITIONS::CTYPECASE
> > >    CONDITIONS::ECASE
> > >    CONDITIONS::CCASE ))
> > > 
> > > (setq lisp_unexport
> > >  '(LISP::LAMBDA-BLOCK-CLOSURE
> > >    LISP::BYE
> > >    LISP::QUIT
> > >    LISP::EXIT
> > >    LISP::IEEE-FLOATING-POINT
> > >    LISP::DEFENTRY
> > >    LISP::VOID
> > >    LISP::ALLOCATE-CONTIGUOUS-PAGES
> > >    LISP::UNSIGNED-SHORT
> > >    LISP::DOUBLE
> > >    LISP::BY
> > >    LISP::GBC
> > >    LISP::DEFCFUN
> > >    LISP::SAVE
> > >    LISP::MAXIMUM-CONTIGUOUS-PAGES
> > >    LISP::SPICE
> > >    LISP::DEFLA
> > >    LISP::ALLOCATED-PAGES
> > >    LISP::SUN
> > >    LISP::INT
> > >    LISP::USE-FAST-LINKS
> > >    LISP::CFUN
> > >    LISP::UNSIGNED-CHAR
> > >    LISP::HELP
> > >    LISP::HELP*
> > >    LISP::MACRO
> > >    LISP::*BREAK-ENABLE*
> > >    LISP::CLINES
> > >    LISP::LAMBDA-CLOSURE
> > >    LISP::OBJECT
> > >    LISP::FAT-STRING
> > >    LISP::SIGNED-SHORT
> > >    LISP::MC68020
> > >    LISP::LAMBDA-BLOCK
> > >    LISP::TAG
> > >    LISP::PROCLAMATION
> > >    LISP::ALLOCATED-CONTIGUOUS-PAGES
> > >    LISP::*EVAL-WHEN-COMPILE*
> > >    LISP::SIGNED-CHAR
> > >    LISP::*IGNORE-MAXIMUM-PAGES*
> > >    LISP::*LINK-ARRAY*
> > >    LISP::KCL
> > >    LISP::BSD
> > >    LISP::ALLOCATE-RELOCATABLE-PAGES
> > >    LISP::ALLOCATE
> > >    LISP::UNIX
> > >    LISP::MAXIMUM-ALLOCATABLE-PAGES
> > >    LISP::ALLOCATED-RELOCATABLE-PAGES
> > >    LISP::SYSTEM
> > >    LISP::KYOTO
> > >    LISP::CCLOSURE))
> > > 
> > > (make-package "COMMON-LISP" :nicknames '("CL"))
> > > 
> > > (do-external-symbols (s "LISP")
> > >   (if (not(member s lisp_unexport))
> > >       (import s "COMMON-LISP")))
> > > (import 'lisp:nil "COMMON-LISP")
> > > 
> > > (do-external-symbols (s "PCL")
> > >   (import s "COMMON-LISP"))
> > > 
> > > (do-external-symbols (s "CONDITIONS")
> > >   (if (member s clcs_shadow)
> > >       (shadowing-import s "COMMON-LISP")
> > >       (import s "COMMON-LISP")))
> > > 
> > > (do-symbols (s "COMMON-LISP")
> > >   (export s "COMMON-LISP"))
> > > ;;;(export 'common-lisp::nil "COMMON-LISP")
> > > 
> > > (make-package "COMMON-LISP-USER" :nicknames '("CL-USER") :use
> > > '("COMMON-LISP"))
> > > (import 'lisp:nil "COMMON-LISP-USER")
> > > 
> > > (in-package "CL-USER")
> > > ----------------------------------------------------------------------
> > > 
> > > Unfortunately the above code doesn't work as expected (at least as
> > > I expect it to work ;-). The problem is with NIL symbol.
> > > And this is a bit strange. First trouble is that I export doesn't want
> > > to make it external symbol of newly created COMMON-LISP package.
> > > GCL executes the following code
> > > 
> > > (make-package "FOO")
> > > (import 'lisp:nil "FOO")
> > > (export 'foo::nil "FOO")
> > > 
> > > without any error or warning but external symbol foo:nil is
> > > not created.  The same code (with lisp:nil replace by cl:nil)
> > > works well on CLisp and fails on CMUCL like in GCL.
> > > I'm not quite sure which way is correct since NIL is quite
> > > special symbol but it seems to me that (export nil ...) is buggy in
> > > both GCL and CMUCL.
> > 
> > I'm surprised that CMUCL would have a bug of this nature.  Are you
> > sure that nil isn't some implied default in all packages or somesuch?
> > Does the clocc test complain about a missing nil?
> > 
> > > 
> > > The second trouble is once again with NIL but now with
> > > respect to COMMON-LISP-USER package. Since NIL is not
> > > external symbol in COMMON-LISP it is not imported into
> > > COMMON-LISP-USER by make-package.  But the real trouble
> > > is that subsequent
> > > (import 'lisp:nil "COMMON-LISP-USER")
> > > does not do the job either! Once again it executes
> > > without visible error or warning NIL is not placed in
> > > COMMON-LISP-USER!  Very strange since it worked
> > > for COMMON-LISP earlier. Actually it is turned out that
> > 
> > I'm not sure if I follow.  You've imported nil into common-lisp, but
> > cannot export, and cannot import into common-lisp-user to begin with?
> > How do you know you've got it in common-lisp if you cannot export it? 
> > 
> > > 
> > > (make-package "COMMON-LISP-USER" :nicknames '("CL-USER") )
> > > (import 'lisp:nil "COMMON-LISP-USER")
> > > 
> > > works while
> > 
> > What is the sign of 'working' here?
> > 
> > > 
> > > (make-package "COMMON-LISP-USER" :nicknames '("CL-USER") :use
> > > '("COMMON-LISP"))
> > > (import 'lisp:nil "COMMON-LISP-USER")
> > > 
> > > not.
> > > 
> > > I'm a bit puzzled :-(
> > > 
> > 
> > You are doing great!  I think we're close.  In any case, you can
> > probably run the clocc test with what you've got, no?  Any reasonable
> > results? 
> > 
> > Take care,
> > 
> > > Vadim
> > > 
> > > --
> > >      Vadim V. Zhytnikov
> > > 
> > >       <address@hidden>
> > >     <address@hidden>
> > >      <address@hidden>
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>

pcl-clcs-gcl.patch
Description: Text document