[Top][All Lists]

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

RE: [Axiom-commit] [Axiom-developer] Re: SVN: axiom: [266]branche

From: Bill Page
Subject: RE: [Axiom-commit] [Axiom-developer] Re: SVN: axiom: [266]branches/build-improvements/src
Date: Sat, 18 Nov 2006 15:54:38 -0500

On November 18, 2006 2:40 PM Gaby wrote:

Bill Page wrote:
> ... 
> | No. I am referring to the fact that mutual dependencies in the
> | Algebra code are not fully satisfied by the current
> | 
> |   bootstrap (Lisp) -> rest of algeba -> bootstrap (spad)
> | 
> | process. It is necessary to add another iteration
> | 
> |         ... -> rest of algeba -> bootstrap (spad)
> | 
> | before the Lisp code that is generated from SPAD is the same
> | if the iteration is again repeated (SPAD/Lisp code generation
> | achieves a "fixed point").
> If we had a way to gradually extend a domain, we would leave much
> of the categories dragged in out form the bootstrapping process
> and add them only for the purpose of building the installed
> alegbra.  No?

Yes, the bootstrap might be simpler however it would mean that we
would have to separate existing source code modules into multiple
modules, some of which extend others. But I don't think it would
solve the fundamental problem that there are some cycles of
module dependencies that are irreducibly mutually recursive. The
only way of solving this without iteration of the whole algebra
build would be if we could somehow locate all such dependencies
within a single modules and let the compiler solve the recursion.
I think that this might have been the strategy that the original
developers had in mind since Aldor is specifically able to compile
such code within a single module.

It is still not clear to me how the bootstrap mode flag might
help this situation. I think it would only permit the modules
to be pre-compiled in a more arbitrary order. They could then
be compiled "for real" in a second pass. The way Tim solved
this was to provide actual bootstrap code for selected modules
in the form of previously generated Lisp and then to compile
the rest of the modules in a carefully choosen order.

> [...]
> | > Given that, I would like to temporarilly revert the patch
> | > and work it out in fuller details.  Opinions?
> | > 
> | 
> | I believe the current patch is harmless when it comes to the
> | possible proclaim optimization and that it does achieve the
> | goal of database optimization (which is a separate issue).
> | Personally I don't see anything to gain by reverting it.
> It adds a confusion over an existing tower of confusions. 

Ok. Maybe true. But as you said: documentation of what this is
doing is critical.
> Frankly, we all think that the current makefile is a mess.
> Unfortunately, the patch adds to that mess even thought it
> originally intended to do something good.

I am all for more simplicity but making something like the
Axiom build simple is likely to take a lot of time and some
more inspiration.
> Yes, it optimizes the database build but it does not test the
> result. I'm less concerned about not doing the proclaim
> optimization than testing that nothing is broken by the
> database optimization. My proposal is to achieve its goal
> in a more systematic way.  

Ok. I does make sense to me to treat optimization issues
in a different branch.
> This ultimately raised the issue of how to enforce testsuite
> and the whole build process.  I don't have much time left this
> afternoon. I know of DejaGnu framework and the QMTest framework
> for running testsuite.  I have far more extensive experience
> with DejaGnu than with QMTest.  On the other hand, I'm pretty
> sure people would object to DejaGnu for various reasons.

What reasons?

I took a quite look at DejaGnu.

I did not see anything to which I would immediately object.

Bill Page.

reply via email to

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