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

[Bill Page]

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.
 
> | I did not notice this change
> | in Waldek's patch, but it is not unexpected to me. Perhaps
> | Waldek does this also because in the etc/Makefile he has just
> | re-built the databases. It is conceivable that new databases
> | could affect the code that is generated by the algebra compiles.
> 
> then the algebra files should be rebuilt, no?
> 

Yes, I think that might be necessary.

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

> ...
> | 
> | I recall now that Camm Maquire did include the "compile Axiom
> | twice" optimization in the Debian build.
> 
> If we want to do that optimization, then we must build AXIOMsys
> only twice, I think.  And we must do the same step twice.  Here,
> the patch is doing something different the second time.

I agree.

> 
> | Indeed the build log shows that AXIOMsys is built twice
> | although the lisp source is not re-compiled which I believe
> | is required for the function call optimization.
> 
> Yes.
> 
> | (Full SPAD re-compile is required for the fixed-point solution.) 
> 
> that is true, but it is a different issue from the optimization.
> The full SPAD issue is there because because we have no way of
> extending domains gradually.

No. The SPAD issue is there because there are mutual dependencies.
Gradually extending domains does not solve this problem.

> ...
> | 
> | If we really want to do this optimization, then I guess you are
> | right that this patch needs to be re-evaluated.
> 
> I would suggest that we address the optimization latter -- put it
> on the list of README.build-improvements so that we don't forget 
> about it.
>

Yes. Good idea.
 
> | In order to do
> | the optimation, it is necessary to retain the *.NRLIB directories
> | and in particular the *.fn files which contain the necessary
> | "proclaim" information from the 1st build for use in the 2nd.
> | But the current build procedure deletes the NRLIBs doesn't it?
> 
> yes, it deletes the existing NRLIBs.  
> However, I'm not sure where whole SPAD needs to be recompiled, or
> only AXIOMSsys.   I believe it is AXIOMsys only.  In that case, we
> need to keep the previous .fn and .data files for latter use.  And
> it should be planned ahead.

Yes.

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

Regards,
Bill Page.