Re: [Axiom-developer] other diff-Naur changesets

[Waldek Hebisch]

> So you're proposing:
> 
> 4.0 ANSI lisp
> 4.1 Autoconf
> 4.2 Hyperdoc
> 
> Frankly, I'm happy to merge changesets that add any SINGLE facility.
> Or changesets that fix any SINGLE bug. We can increment any number 
> in any field you like. Perhaps we need a "schedule" of changesets?
> 
> 
> I invite anyone who has a changeset to post a diff-Naur of the changeset.
> 

Many changes made to wh-sandbox depend on new build machinery.  For
example to make Hyperdoc functional I had to:
1) fix a buch of bugs, some is lib, some in interp and some in
   hyper subdirectory
2) correct paths embedded into various files
3) intall files in correct places

Part 3 was done mostly in Makefiles, part 2 depended on Makefile
changes.  One can try to separate 1 (ordinary bug fixes), but
without 2 and 3 the fixes are useless and hard to test.

Similary for ANSI compatibility we have various fixes:
1) Plain bugs which in default GCL mode (safety 0) gave undetected
   memory corruption
2) Few things that ANSI GCL 2.6.8 do not accept
3) Things things that clisp/sbcl do not accept
4) Things accepted by clisp/sbcl which work differently than GCL
5) Few thing that "work" but are ANSI violation and produced
   warnings
6) Changes to build process to support clisp, sbcl and openmcl

I one just want to work with ANSI GCL one could try to just pick
part 2.  But IMHO this would be misguided -- we should fix bugs
as soon as possible and 1-5 are just bug in a single logical
category.  Without 6 it is hard to test that fixes really worked.

On more basic level: currently I can not build out of the box 
gold or silver.  Silver recently made big progress: it used to
fail early in the build process, now it fails during graphic
build (it can not find libXpm.a).  To make things clear: I can
edit by hand silver Makefiles so that it build on my
machine.  I know how libXpm problem is solved in
build-improvements and wh-sandbox and I could probably prepare
some fix which applies to silver.

But the point is that to reliably solve problems with X libraries
one needs something like configure/autoconf.  Also,
build-improvements contains many fixes (possibly hundreds of fixes)
to many little problems which surfaced on various machines.

So I would say that build machinery is the first part which
should be merged.  I am affraid that the only realistic way
to do such merge is as a single rather large block.  I will
write separately about dependencies between various parts
and possiblities to do merge in stages.  However, my
conclusion is that doing merge in stages requires much
extra work and there is good chance that intermediate
stages will be more or less broken.

-- 
                              Waldek Hebisch
address@hidden