[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branche
From: |
Bill Page |
Subject: |
RE: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src |
Date: |
Sat, 18 Nov 2006 12:45:38 -0500 |
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.
- Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src, Gabriel Dos Reis, 2006/11/17
- Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src, Gabriel Dos Reis, 2006/11/18
- Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src, root, 2006/11/18
- RE: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src,
Bill Page <=
- Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src, Gabriel Dos Reis, 2006/11/18
- Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src, Ralf Hemmecke, 2006/11/18
- Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src, Martin Rubey, 2006/11/18
- [Axiom-developer] AxiomUnit, Ralf Hemmecke, 2006/11/18
- [Axiom-developer] Re: AxiomUnit, Martin Rubey, 2006/11/19
- [Axiom-developer] AxiomUnit, DejaGnu, and QMTest, Bill Page, 2006/11/20
- [Axiom-developer] Re: AxiomUnit, DejaGnu, and QMTest, Martin Rubey, 2006/11/20
- RE: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src, Bill Page, 2006/11/18
- Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src, Gabriel Dos Reis, 2006/11/18