[MIT-Scheme-devel] Re: [Bug-mit-scheme] Trouble Compiling

[Noah Lavine]

This email brought up a question which I thought I should raise on the devel list. I too ran into the circularity issue, although I eventually got it working with help from the bug list, but it still took some work, and I forget exactly how I did it.

Making snapshots will work, but it seems like the second-best solution, because it requires anyone who wants to build MIT Scheme to download a new binary, when many users might be using a Linux distribution which will provide them with an older, conveniently-packaged binary that they might prefer to use. Also, it requires all new developers to know about the snapshots and go get one, although I suppose that could be solved with a comment in the source code.

However, it seems to me that it is very rare that someone would actually need a binary with new primitives (Matt's case excepted) to build an old version of MIT Scheme. In the star-parser case, it sounds like all you needed was the new Scheme code. Furthermore, all of the scheme code you needed was there already in the source tree of the new build. So, is it possible to change the build process so scheme first loads the .scm files in the new source tree, and then builds scheme?

Noah Lavine

On Sun, Jan 4, 2009 at 7:16 PM, Matt Birkholz <address@hidden> wrote:

> 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
recipe.

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.


_______________________________________________
Bug-MIT-Scheme mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-mit-scheme