Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src

[Gabriel Dos Reis]

"Bill Page" <address@hidden> writes:

| On November 18, 2006 2:34 AM Gaby wrote:
| > 
| > Bill Page writes:
| > 
| > | 
| > | Building Axiom twice is normal practice in order to obtain
| > | optimized function calls in gcl.
| > 
| > Ahem, it is new -- not "normal" build process :-).  I believe the
| > build system on trunk does not build twice.
| >
| 
| I meant we have discussed this many times on this list (not
| recently) and that others have experimented with such a build
| process - in particular Camm in the Debian build of Axiom.

Aha, OK.

[...]

| > | In fact, compiling twice also turns out to be the minimum
| > | required due to some mutual dependencies that are not fully
| > | resolved by the current bootstrap procedure. (See previous
| > | discussion of the algebra fixed-point iteration tests that
| > | I did over a year ago.) But that is a different issue.
| > 
| > if you're referring to the $boosttrap hack, yes, I believe that
| > is a different issue.  It does not appear to me that this change
| > is actually planned and intended by the patch.
| 
| 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?

[...]

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

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.

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.  


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.

-- Gaby