[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-mit-scheme] Trouble Compiling

From: Matt Birkholz
Subject: Re: [Bug-mit-scheme] Trouble Compiling
Date: Sun, 4 Jan 2009 17:16:57 -0700

> From: Taylor R Campbell <address@hidden>
> Date: Sun, 21 Dec 2008 11:38:56 -0500
> What version of Scheme are you using to build Scheme?  There was a
> change last year (a definition of CREF/PACKAGE-FILES, and subsequent
> use of it in the build scripts) that required the use of a newer
> snapshot to build it.  The 2008-01-30 snapshot should work.

The 2008-01-30 snapshot does not work.  I just tried it on CVS HEAD
and it failed in various interesting ways.

The incompatibilities between the Scheme machine and my OS (Ubuntu
Intrepid) were easily solved, as seems to be the case for Noah, but a
working binary distribution is only the first hurdle.  As Taylor
hints, you actually need a RATHER RECENT binary distribution
installed.  Otherwise you will have problems with "version skew" (for
lack of a better term), like the missing CREF/PACKAGE-FILES binding.

I re-built the 2008-01-30 machine from patched microcode because of
missing shared libraries and the default (bitchy) AppArmor config in
Ubuntu Intrepid.  Yet my build STILL failed because runtime/
http-syntax.scm uses a new star-parser operator (encapsulate*) that is
not implemented in the 20080130 snapshot.  Breaking THIS circularity
was a trick; I eventually removed http-syntax from the initial build
process (hacking runtime.pkg and make.scm) to get a band with the new
star-parser.  Then I was able to add http-syntax back in and build a
complete runtime.

It is unfortunate that potential new contributors to MIT Scheme should
immediately run into problems because of these "circularities".  They
want to build from the latest sources before reporting bugs or
formulating patches, but they need a binary distribution containing
the very latest code or their build will fail.

This seems to happen quite a lot, and it takes an experienced
developer to break the circularities.  An extreme example is the move
to distinct #f and '() objects.  Chris said he had to go through
several stages before he had an mit-scheme that could build the new
mit-scheme.  He could hardly remember the process, much less give a

This version skew (incompatibilities between the last snapshot and CVS
HEAD) seems unavoidable in a system that uses its own best tools to
build itself.  But how do we stop turning away new contributors with
tricky "circularities" that frustrate their attempts to catch us up?

I think we need to provide more snapshots.  I propose to set up a
nightly build on a machine running the latest Ubuntu and binary
distribution.  It will grab CVS HEAD and attempt a build.  If it
fails, I will fix it and upload a new binary distribution, maybe even
describe the "circularity" and how I broke it.  I assume such
snapshots will only be necessary a few times each year, and the
resulting all.com bands will be useful to anyone on a Unix-like,
i386-like host.

This all came to a head when I tried to add my FFI to CVS HEAD.  The
resulting system cannot be built except by a machine that includes the
FFI's new primitives -- another of those pesky circularities!  My next
release will be a big patch to CVS HEAD, *and* a binary distribution
for i386-unix that can build it.

reply via email to

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