axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] 2.7 build


From: Stephen Wilson
Subject: Re: [Axiom-developer] 2.7 build
Date: 13 Jul 2007 19:39:01 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Hello,

Sorry for the delay on this!

I have collected a set of patches which I belive approximate what we
need to get Silver building atop gclcvs-2.7.0 in ANSI mode.  I am
still having issues during the final rebuild of the databases, but the
algebra as a whole compiles.

This patchset does not represent the absolute minimum of changes
necessary for the build.  But it strives to be fairly lightweight.

A large number of the changes are temporary workarounds and need
better solutions.

Waldek, I belive wh-sandbox might address some of these issues
properly.  Perhaps we can use this patchset as a baseline to recover
some of the wh-sandbox efforts and present a changeset for Silver in
time?



To make use of the patch get a fresh checkout of Silver and then:

     cd silver && patch -p1 < silver-gclcvs.patch



Notes about the patchset:


!!!!
One needs to have the latest gclcvs-2.7.0 built and installed in your
$PATH.  The makefiles assume the existance of the command `gcl'.  The
image used to build the system (obj/${SYS}/bin/lisp) is generated via
COMPILER::LINK, with the necessary axiom objects included, and
SI::*DISABLE-RECOMPILE* set to T.

Moreover, if gcl is updated, it suffices to do a `rm lsp/gcldir' to
eliminate a tag file used to indicate the build image has been
generated.  Upon remake, the new gcl in $PATH will be used to link a
fresh image, with minimal recompilation of the tree.
!!!!


The build does not use interp-proclaims.lisp, nor generate *.fn's,
nor invokes COMPILER::MAKE-PROCLAIMS.

sys-pkg.lisp is reworked, and is not in a final form.  Some conflicts
exist in the original silver code, so this file needs a subset of
these changes.  More generally, the bulk of the work is to use
DEFPACKAGE, and to name the symbols therin by strings.  This is a
personal preference as a great many symbols are mixed case in the
axiom code base.  I find the strings "FOOBAR" and "FooBar" easier to
distinguish than 'foobar and '|FooBar|, and I belive this usage might
reduce the chance for programmer error. In addition, the BOOT package
is devoid of exports, as it has no clients.  I am not commited to the
overall form of this change, as it is a result of lifting the diff
from a personal branch.

I eliminated calls to SI::ALLOCATE as I found the current calls
resulted in some issues during debugging.  These calls need to be
retooled. 

A few changes were needed due to incompatabilities with the new
pathname semantics.  In particular, *DEFAULT-PATHNAME-DEFAULTS* is
left untouched.  Other temporary changes were needed until we can
normalize Axioms handling of pathnames.

An unnecessary change but one included regardless is the factoring out
of a few functions previously defined in FLET's in daase.lisp.pamphlet.
This is simply an aid for debugging purposes.

Certain changes were needed in the algebra.  For some reason Spad
functions of the form:
    foo(n: Integer): Integer ==
       if zero? n then
         x := 1
       else
         x := 2
       x
do not compile, and need an explicit type declaration at the points of
assignment to x.  This needs to be fixed.

I needed to tweek the algebra layers in one case as I found an
autoload dependency conflict.  I have yet to analyze this case.

The file allfact.spad apparently has an algebra bug which needs to be
fixed, but was not picked up < 2.7.0 builds.  I simply hacked in a
change which allows the build to progress.  I recently posted an email
to axiom-developer regarding this issue. See:
 http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00270.html

Aside from a few mismatched parens, special declarations, and the
removal of some minor bitrot, thats pretty much it.



And of course, I can try to answer any further questions, and help
address any outstanding/overlooked issues.




Sincerley,
Steve


Attachment: silver-gclcvs.patch
Description: Text Data


reply via email to

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