[Openmcl-devel] Debian packaging for CCL
faheem at faheem.info
Mon Jul 16 22:09:16 PDT 2012
On Mon, 16 Jul 2012, R. Matthew Emerson wrote:
> On Jul 16, 2012, at 11:11 AM, Faheem Mitha wrote:
>> On Mon, 9 Jul 2012 22:43:53 -0400, R. Matthew Emerson <rme at clozure.com> wrote:
>>> Regarding source code, I believe that many programmers find it
>>> helpful to have the source code of the lisp implementation around,
>>> too. This way, you can M-. right into the source code of
>>> with-open-file (or whatever).
>> Can someone tell me which files in the CCL source repository are
>> considered to be source code? I want a comprehensive list, which I can
>> use to construct a ccl-source package. Thanks.
> svn export http://svn.clozure.com/publicsvn/openmcl/trunk/source
> will get you the complete sources for trunk CCL. This won't include
> the interface databases or bootstrapping binaries needed to compile
> the sources.
> You'd use a similar path for the release branch:
> svn export http://svn.clozure.com/publicsvn/openmcl/release/1.8/source
> The source directory takes up about 29 megabytes of space, and this
> includes some sub-directories that might not be not that useful
> for Linux (e.g., cocoa-ide).
Thanks. This brings up the question - what code should I be using, and
from where, to build the binary?
Currently, I have been using
the documentation in
188.8.131.52.2. Downloading a Release Version
which appears to be equivalent to the tarball in
Debian tends to prefer upstream tarballs, so this latter tarball would
appear to be the version to choose. However, the problem is that you
ship binaries along with the source code in these versions. Granted,
this is useful to build on a system which does not already have a
working CCL compiler installed, but it has the complicating factor
that on build the existing binaries, in this case lx86cl, lx86cl.image
are overwritten by the build, which causes problems. Debian expects
that there is a clean target in debian/rules (the debian build
script), which returns the upstream source to a pristine condition, as
it originally was before build. This is much more difficult if the
binaries are overwritten on build, as is the case here. This is
probably a question to ask Debian, but perhaps you have an opinion
Note that I have worked around the existence of the binaries by
writing the build files elsewhere, but this is been a pain, and
obviously it would be preferable not to have to do so.
However, using just the sources as you have listed them, then raises
the question - what compiler do I use to build with - do I use the
binary packaged version of CCL in debian to build the source for
itself? That seems a little weird.
More information about the Openmcl-devel