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

[Waldek Hebisch]

Gabriel Dos Reis wrote:
> Waldek Hebisch <address@hidden> writes:
> 
> | Gabriel Dos Reis wrote:
> | > False alarm -- they are built "early".  
> | > 
> | > However.
> | > 
> | > I think I have a better understanding than I had three hours ago.
> | > The last test I did was with revision 283.
> | > 
> | > In that revision, the whole AXIOMsys seems to be built twice:
> | > 
> | >   (1) once as usual
> | >       - then the testsuite is run
> | >   (2) and a second time
> | >       - this time it is not tested any more.
> | >       - this time, the other component are not built
> | >
> | 
> | For me that is not a new behaviour:  I have a build log from October 24
> | and I see this (I think I have seen this much earlier, but ATM I can not
> | find build logs).
> 
> That is not what I see from building any version before 266.
>

Running:

grep -n '^\(1 making a \|37 making \|4 rebuilding databases\|29 making 
\|.*regression-tests\|.*make axiomsys\)' mlogg

(where mlogg is caputred output from make) gives me:

5131:29 making ./algebra
8911:37 making /var/tmp/hebisch/axp19/ax-build1/int/etc
8914:4 rebuilding databases...
14399:(cd ../interp &&  make axiomsys)
16152:make DAASE=/var/tmp/hebisch/axp19/ax-build1/target/x86_64-unknown-linux 
regression-tests
97009:1 making a x86_64-unknown-linux system, PART=cprogs SUBPART=everything
97528:29 making ./algebra
97620:37 making /var/tmp/hebisch/axp19/ax-build1/int/etc
97622:(cd ../interp &&  make axiomsys)
97989:make DAASE=/var/tmp/hebisch/axp19/ax-build1/target/x86_64-unknown-linux 
regression-tests

Before version 266 I saw almost the same picture: only the 'make axiomsys'
lines were missing. As you can see the build process is run twice,
including the rule that I added.  We enter input directory twice,
each time after building AXIOMsys.  Why we do not run regression-tests
the second time?  Well, that is usual make logic: since .output files
depend only on .input and miss dependency on ${TESTSYS} make thinks
that .output files are up to date and do not regenerate them. 

AFAICS we run the build process twice because of top level Makefile
rules:

all-ax:
        @ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
        @ echo 2 Environment ${ENV}
        @ $(MAKE) stamp-rootdirs
        @ ${ENV} $(MAKE) $(src_stamp)
        @echo 3 finished system build on `date` | tee >lastBuildDate

....

$(src_stamp): $(lsp_stamp)
        cd $(build_srcdir) && $(ENV) $(MAKE)

So we first enter src directory from the recursive part and then the
second time from $(src_stamp) rule.  If you want to avoid second
build just remove the stamp parts from 'all-ax' rule.

Another question is why anything gets rebuild during second run?
interpsys is re-build due to dependency:

$(SAVESYS): $(axiom_build_bindir)


building interpsys changes timestamp of $(axiom_build_bindir) and
triggers re-building of interpsys on the next run.  After removal
of this rule (and stamps part from 'all-ax' rule) re-running make
(with onchanged source directory) did not rebuild anything.


> Before your patch, building interpsys also builds AXIOMsys (which is a
> copy of interpsys).  Why it must be a copy and not just the original
> image, I don't know.  But that is what it is.  Now with your patch,
> AXIOMsys is built differently from interpsys after interpsys, and
> interpsys is tested but not AXIOMsys (which is installed).
> 

We can easily change input Makefile to test AXIOMsys.  We also
may add dependency on AXIOMsys, so that test are re-run when
AXIOMsys changes.  However, I think we should _not_ run the
tests after re-making AXIOMsys: tests take 15-20 minutes to
run and that IMHO is unacceptable during developement.  In other
words, during developement tests must run exactly when requested.

I think we should have a separate target to build, latex things
and run test and a sepatate target for developement.  I would
prefer to use plain 'make' as a developement target (plus
'make dvi' and 'make check') and 'make build' as a shorthand
for 'make && make dvi && make check', but other arrangements
are also acceptable.

-- 
                              Waldek Hebisch
address@hidden