[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructio
From: |
John Jorgensen |
Subject: |
Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions. |
Date: |
Thu, 6 Jun 2002 10:37:48 -0400 (EDT) |
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
- [Gcl-devel] conditions/clos/gcl unified build patch and instructions., John Jorgensen, 2002/06/04
- [Gcl-devel] Re: conditions/clos/gcl unified build patch and instructions., John Jorgensen, 2002/06/04
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Vadim V. Zhytnikov, 2002/06/05
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Camm Maguire, 2002/06/05
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Vadim V. Zhytnikov, 2002/06/06
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Camm Maguire, 2002/06/06
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Vadim V. Zhytnikov, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Camm Maguire, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Thomas F. Burdick, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Camm Maguire, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., John Jorgensen, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Camm Maguire, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Vadim V. Zhytnikov, 2002/06/07