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: Waldek Hebisch
Subject: Re: [Axiom-commit] [Axiom-developer] Re: SF.net SVN: axiom: [266]branches/build-improvements/src
Date: Sat, 18 Nov 2006 12:10:45 +0100 (CET)

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).
 
> 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. 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).


> 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.
 
> 
> 
> 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.

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

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