axiom-developer
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]