[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvement
From: |
Waldek Hebisch |
Subject: |
[Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src |
Date: |
Tue, 21 Nov 2006 01:47:15 +0100 (CET) |
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