[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: |
Gabriel Dos Reis |
Subject: |
Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src |
Date: |
18 Nov 2006 08:33:40 +0100 |
"Bill Page" <address@hidden> writes:
[...]
| > First, we should not build twice. Second, if we must build
| > twice, then we must test the second version -- the one that
| > is installed.
|
| 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 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?
| 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.
| > Finally, I think we must rewrite the patch to src/etc/ that
| > introduces this new behaviour.
| >
|
| I agree that it needs further explanation.
it needs more than explanation, because we don't know whether the
rebuild may affect the generation of the algebra files.
[...]
| On November 15, 2006 2:43 PM Waldek Hebisch wrote:
| >
| > The following patch makes caching of databases effective and
| > reduces startup time of AXIOMsys. Debian uses similar patch
| > and claims huge reduction of time needed to run tests, but
| > for me test time remained effectively unchanged.
| >
| > diff -ru build-improvements.bb/src/etc/Makefile.in
| > build-improvements/src/etc/Makefile.in
| > --- build-improvements.bb/src/etc/Makefile.in 2006-11-15
| > 13:15:29.000000000 +0100
| > +++ build-improvements/src/etc/Makefile.in 2006-11-15
| > 13:46:07.000000000 +0100
| > @@ -14,6 +14,7 @@
| > $(axiom_target_libdir)/summary \
| > $(axiom_target_libdir)/copyright \
| > $(axiom_target_bindir)/axiom
| > + (cd ../interp && $(ENV) $(MAKE) axiomsys)
| > @echo 6 finished $(builddir)
| > -rm -f stamp
| > $(STAMP) stamp
| > ...
|
| 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.
| 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.
| The regression tests were
| not re-executed. Perhaps there is a missing dependency in the test
| stanza. But you are right. It makes sense to run the tests only
| after the 2nd build.
|
| 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.
| 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.
Given that, I would like to temporarilly revert the patch and work
it out in fuller details. Opinions?
-- Gaby
- 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 <=
- 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, 2006/11/18
- 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