>>>>> "Rupert" == Rupert Swarbrick <rswarbrick at gmail.com> writes:
Rupert> [If you don't care that much, and just want to check I haven't broken
Rupert> your build, skip down to the line of stars]
I'll test this soon.
Rupert> I *was* going to suggest that building all the automatically generated
Rupert> files could be part of the job of rolling a tarball. But some of them
Rupert> require the relevant implementation to generate them. For example, you
Rupert> really need a copy of SCL to make scl-depends.mk and so on. So, I think
Rupert> there are three options:
I only took a very quick look, but maxima.system defineds the lisp
source dependencies, and for the most part, all of the Lisp
implementations have the same set of dependencies. It looks like only
gcl has a few different files (like sys-proclaim).
Rupert> (1) The status quo. Use checked-in copies of automatically generated
Rupert> files. These may or may not be in date. Those that are used less
Rupert> often (eg ones for Windows users or proprietary lisps) might be
Rupert> massively out of date.
Rupert> (2) Tell anyone wishing to compile Maxima that they must run "make" at
Rupert> least once in the source tree. This will sort out all of those
Rupert> pesky automatic files for them and then they can go back to the
Rupert> Lisp world from then on.
Rupert> (3) Try to support a couple of configurations with no Makefile. That
Rupert> is, when we roll a tarball we make sure to build all the files that
Rupert> are needed for compilation with GCL, say. This wouldn't be a
Rupert> ridiculous workload / expense for the release manager, but it could
Rupert> support some Make-less users.
I think we should do all or nothing. Leave things as they are, or
drop "official" support for a lisp-only build. A "half-way" solution
is just more work.
Rupert> Second question: Why are we installing copies of the lisp
Rupert> implementation? At the moment, the install targets for Clisp and SCL
Rupert> both make copies of the lisp implementation and stick them in the
Rupert> installation directory. The CMUCL and SBCL targets try/tried to do this,
Rupert> but for SBCL, at least, we don't do it right.
Rupert> Is there a reason for this behaviour? I see legality issues with SCL
Yes. For cmucl and sbcl, the maxima.core file is pretty specific to
the version that was used to create it. You can't load up the
maxima.core with an arbitrary version. Sometimes, it fails outright,
but other times it looks like it's working but it the breakage shows
up in subtle ways.
I would think this is also true for the other lisps, except gcl (and
ecl?) where you get a complete executable. But cmucl and sbcl can
also create executables, so you could install the executable instead
of maxima.core and the lisp runtime.
Rupert> (having just had the pleasure of reading their licence document). And on
Rupert> SBCL/CMUCL, this is completely silly since none of the required support
Rupert> files for the implementation get installed. Is anyone using this?
On the rare occasions that I actually install, I am using this
feature. I see, though that with cmucl I get a warning about the
startup code not matching the core version. A bug perhaps?
Ray