[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


"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

> 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

        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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]