[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: ANSI and CltL1 installers for Windows
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: ANSI and CltL1 installers for Windows |
Date: |
05 Jan 2004 13:36:33 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
"Mike Thomas" <address@hidden> writes:
> Hi Camm.
>
> First, I put together an installer for the stable branch (CLtL1) per CVS
> today and expect it should be on your download site within 24 hours. The
> file name is "gcl_2.6.1.mingw32_japi_xdr_20040105.zip".
>
Great! I'm running the temporary website update script by hand now,
as we're close to getting things going again on ftp.gnu.org.
> Hopefully the problems Bill had with the system directory and installation
> are gone.
>
>
> Second, rather than building separate installers for ANSI and CLtL1 builds I
> would prefer to have both executables in a single installer (with separate
> start menu shortcuts etc) until we don't need a CLtL1 build on Windows.
>
OK. Please know that at present, maxima requires the ansi build,
which acl2 and axiom require the traditional build :-). I handle this
in Debian by shipping both images, and toggling with the environment
variable GCL_ANSI. We could do something like this by default if we'd
like.
> This raises the question of whether there is, or will be in the future,
> substantial difference between the "saved_gcl" produced during a CLtL1 build
> and the "saved_gcl" produced as an intermediate step in the production of
> "saved_ansi_gcl.exe" during a "configure --with-ansi" build.
>
There are a few differences in the core files, all escaped with #ifdef
ANSI_COMMON_LISP:
1) Old vs. new in-package behavior
2) common-lisp package and common-lisp-user package
3) new symbols
There may be others, but it should be straightforward to search for
them in the o/ dir. In short, the two saved_gcl images are not the
same. acl2 will complain if it finds the common-lisp-user package,
and axiom needs the old in-package.
> As it is PCL which is causing instability on Windows, maybe we can provide a
> stable ANSI build modulo PCL until that problem is fixed. That would
> hopefully be sufficient (in the interim) for Maxima, ACL2 and Axiom
> development on Windows, as I believe they do not require CLOS.
>
> What do you think?
>
If you can determine that the maxima users won't be using pcl in the
near future at least, we could put in a configuration option of this
sort. I'd prefer to just fix the build if possible of course.
>
> Third, could you please briefly describe the differences between the various
> executables you are producing (especially: What is clcs?):
>
> unixport/raw_ansi_gcl.exe unixport/saved_ansi_gcl.exe
> unixport/raw_gcl.exe unixport/saved_gcl.exe
> unixport/raw_pcl_gcl.exe unixport/saved_pcl_gcl.exe
> unixport/raw_pre_gcl.exe unixport/saved_pre_gcl.exe
GCL images are build in layers -- the raw images are just linked C
functions, the saved images have run initialization code.
pre -- lsp and cmpnew are interpreted in the image (for bootstrapping
the compile)
(vanilla) -- the cltl1 code (alone) is loaded in compiled form
mod -- cltl1 + defpackage, ansi loop and destructuring-bind
pcl -- the above + pcl
clcs -- the above + the conditions package
ansi -- the above with the common-lisp and common-lisp-user packages
setup with all imported and shadowed symbols, etc.
Hope this helps. Take care,
>
>
> Cheers
>
> Mike Thomas.
>
>
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah