[Gcl-devel] Re: [Axiom-developer] Axiom build issues

[root]

> Greetings!  We're preparing for the gcl 2.6.2 stable release, which
> will hopefully be the last stable for quite some time as we turn our
> attention to the development branch.  Of course it is very important
> for us to make sure this release is solid for axiom.  And its looking
> quite good so far -- no apparent build problems (due to GCL) on any of
> the Debian architectures (see
> 
> http://buildd.debian.org/build.php?pkg=axiom 
> 
> if interested).  There are a few small items I'd like to squeeze in,
> the most important being to ensure that GCL exits with non-zero when
> stdin is redirected from a file or pipe and a lisp error is triggered
> -- this will stop the commands executed by make at that point.  And
> there should be an option to quiet the banner.

Actually it would be more useful if the banner were written to a lisp
variable. Then I could manipulate the string into the axiom banner in
a clean way.

> 
> Along these lines, I have a question about the regression tests.  It
> would be nice if the output was compared to results known to be
> correct, with the build bailing out otherwise.  Then one can be sure
> by the mere fact that the build completes that the build is also
> correct, (i.e. without having to wade through the output by hand).  Is
> something like this already in place or possible?

There used to be a regression test run that compared the output.
There are some subtle issues but these are taken care of by that code.
In particular, you need to distinguish between bug that you didn't cause
and bugs you did (while testing boundary cases, etc). To do that you 
  )set msg test on
which is an historical switch I used for exactly this purpose. 
It will generate a "DALYBUG" message when an error occurs. If you
wrap your deliberately failing test by turning this switch on you
can tell that the bug is expected.

I'll put revival of this code on the todo list.

> 
> There are a few other items in the Debian package build which are not
> GCL related per se.  One is that the build will timeout on slow
> machines when compiling expexpand.spad.  As was noted before, there
> appears to be an inordinate amount of mysterious bignum garbage, or at
> least relocatable garbage, being generated here which could be tracked
> down at some point.  For the time being I've put in a hack to echo a
> string every 15min in the background for some period while the make is
> running.  Another alternative would be to turn on si::*notify-gbc*,
> but this would enlarge an already copious output.

This is clearly a bug somewhere. If you can get a clue about what
routine it is running that would focus the search.

> 
> Then there is the question of the outstanding patch we're using in
> Debian now 1) to use an external GCL, and 2) to use compiler::link to
> build the image on machines which cannot do native relocations (alpha
> ia64 mips(el) hppa).  Its fine the way it is, but I'm wondering if at
> some point we can put in an alternate build target in the Makefiles
> supporting these build commands in axiom per se.  I'd be happy to
> maintain them if/when we decide on a rule structure.  The sequence
> right now works without issue, but GCL could make this more
> transparent on these platforms eventually.  Improvements in this area
> should however be put off to the next stable release which will likely
> be quite some time in the future.

We could easily make this change. Look at the top level Makefile.pamphlet.
Each system can have its own Makefile generated. To get this working you


(a) copy the \subsection{Makefile.linux} in Makefile.pamphlet (line 813)
(b) create a \subsection{Makefile.debian} and rename linux to debian.
(c) set your AXIOM variable to:
      AXIOM=(yourpath)/axiom/mnt/debian
(d) type make

and you'll get a Makefile.debian built from your new <<Makefile.debian>>
chunk. You can change that chunk any way you like. 

> 
> On a totally different topic, has anyone written an emacs mode for
> axiom?  I tried out the texmacs interface with the Debian package and
> its broken.  There is a simple isse regarding paths and executable
> names that I can workout with the texmacs maintainer.  But this aside,
> one still gets garbage using the mode, at least for me.

I'm unaware of an axiom emacs mode. Likely it would just be a clone of
an existing mode. Axiom used to have emacs tags automatically generated
so that you could walk among the axiom source files using keystrokes.
Tagging should come back and I believe there is lisp code in Axiom to
create the tags already.

I'll put revival of this code on the todo list.




I've set up axiom for development purposes using the gnu-arch system.
This allows multiple branches for development. If you want to experiment
with GCL related changes we can set up an axiom--gcl--1 branch for you.

Tim