[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 16:39:06 +0100 |
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.
| > I think it is wrong not to test the second time AXIOMsys is built (it
| > is the one that is installed). We would need an explanation of why
| > AXIOMsys needs to be built twice -- the first time it is tested, and the
| > second time it is not.
| >
|
| The rule I added is run _before_ testing.
My build log says otherwise.
The second build happens long after the testsing, with:
[...]
preloading
/home/gdr/build/axiom/target/i686-suse-linux/algebra/INT.o..loaded.
preloading
/home/gdr/build/axiom/target/i686-suse-linux/algebra/LIST.o..loaded.
preloading
/home/gdr/build/axiom/target/i686-suse-linux/algebra/OUTFORM.o..loaded.
Finished loading
/home/gdr/build/axiom/obj/i686-suse-linux/interp/makeint.lisp
6a /home/gdr/build/axiom/target/i686-suse-linux/bin/AXIOMsys created
make[5]: Leaving directory `/home/gdr/build/axiom/src/interp'
6 finished .
rm -f stamp
echo timestamp > stamp
[...]
After AXIOMsys is created, no test is run.
When build control reaches src/interp/ (right after it
leaves src/boot/), it goes on building the images:
all-ax: $(MID) $(AUTO) stamp
@echo 618 finished $(srcdir)
stamp: $(MID) $(AUTO) remove-stamp build-images
$(STAMP) stamp
Building images consists of building interpsys, AXIOMsys and debugsys.
build-images: remove-stamp $(SAVESYS) $(DEBUGSYS)
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).
| However src/input/Makefile
| contains the following (corresponging pamphlet is a mess):
|
| TESTSYS=$(axiom_build_bindir)/interpsys
|
| and later:
|
| $(MID)/%.output: $(MID)/%.input
| (cd $(MID) ; \
| echo running test file $* ; \
| echo ')set message test on' > tmp.input; \
| echo ')set message auto off' >> tmp.input ; \
| echo ')read $*' >> tmp.input ; \
| echo ')lisp (bye)' >> tmp.input ; \
| echo 'systemCommand "read tmp.input"' | ${TESTSYS} | tee $*.output; \
| rm tmp.input )
|
| So, src/input/Makefile deliberatly uses different image than the one
| beeing installed (I do not think it is good idea -- just notice the
| fact).
AXIOMsys and interpsys are supposed to be the same image -- that is
documented in src/interp/Makefile.pamphlet. You and me may not like
it. But when we make changes we must ensure that those invariants hold. We
cannot just blame the existing the . We know the existing
| > The dependencies are wrong somewhere but I don't know yet where.
| > Furthermore, I come realize that the rule
| >
| > (cd ../interp && $(ENV) $(MAKE) axiomsys)
| >
| > is no good. Because by the time the build flow reaches src/etc/ we may
| > already have done lot of things on the way (and we do). Now, it looks
| > like src/etc wants to ask AXIOMsys to be rebuilt a second time,
| > without necessarily "making" other things that might depend on it.
| > That is no good. We should not have the rule written that way.
| >
| > I think we must take a step back and lay down what is that the patch
| > is trying to achieve. And do that in a more controlled way.
| > Waldek?
| >
|
| The whole point is to cache databases into otherwise identical image.
| AFAICS the way to do this it to repeat image building, but pointing
| image at new databases.
We must do that is a more controlled way. Unfortunately, we can't
just do a "local" surgery with "goto" previous build.
I'll see. Interpsys is not installed, I'll see whether its removal is OK.
| > The "generic" errors from hyperdoc are of the form:
| >
| >
--->/home/gdr/build/axiom/target/x86_64-suse-linux/../../src/algebra/ES.spad-->E
| > xpressionSpace((odd? ((Boolean) %))): Unexpected HT command: \spad
| >
| > These may actually be not related to the patch. Sorry for that.
| >
|
| I have seen them for a long time. The reasin is in the following
| function:
|
| buildHtMacroTable() ==
| $htMacroTable := MAKE_-HASHTABLE 'UEQUAL
| fn := CONCAT(getEnv '"AXIOM", '"/doc/hypertex/pages/util.ht")
| if PROBE_-FILE(fn) then
| instream := MAKE_-INSTREAM fn
| while not EOFP instream repeat
| line := READLINE instream
| getHtMacroItem line is [string,:numOfArgs] =>
| HPUT($htMacroTable,string,numOfArgs)
| for [s,:n] in $primitiveHtCommands repeat HPUT($htMacroTable,s,n)
| else
| sayBrightly '"Warning: macro table not found"
| $htMacroTable
|
| This function is supposed to load macros from 'util.ht'. But when
| we do out of tree build 'util.ht' is unavailable during algebra
| build (it is installed later). Also, the path is now wrong and
| I am not sure if AXIOM is set during build.
Then, you have identifier (yet) another bug. Thanks.
-- Gaby