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

[Gabriel Dos Reis]

"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