Ralf Hemmecke wrote:
>
> Hello,
>
> I've finished the p* conversion. Now though I believe to have checked
> the compilation of the .spad files, a fresh compilation of
> fricas/new-lambda with my changes fails. I've compiled via
>
> make -j8 > make.log
>
> and around line 305.000 of make.log there appears "Apparent user
> error:", i.e. the compilation of the .spad file failed.
>
> Clearly, there is an error in my +-> conversion. But that is not my
> problem now.
>
> In make.log I see 6 of those "Apparent user error" messages. Since I
> used -j8 it is clear that one cannot expect immediate abort of the
> compilation.
>
> The build process ended a bit later with an error message and left
> directories PFO.erlib and PMTOOLS.erlib under src/algebra. So I
> completely removed those directories and started again with
>
> make > make2.log
>
> i.e. I continued the build.
>
> Now in make2.log I also find "Apparent user error" in line 736 and I
> would have expected that the build process would stop immediately. But
> the file make2.log is 48310 lines long. It looks as if 'make' does not
> recognize that the compilation of the .spad file went wrong. :-(
>
> The error will only be recognized, if some other file needs the
> corresponding .o file (which of course cannot be found). That looks a
> bit too late to me and is bad for files that are never used during the
> build of FriCAS. I guess, a broken .spad file might slip into a release
> if this file appears late enough in the build hierarchy.
>
I do not think so. All files are explicitly listed and we have
the following copy loop:
for A in ${SPADLIST} ; do \
cp $$A.NRLIB/$$A.$(FASLEXT) ${OUT}/$$A.$(FASLEXT) || exit 1 ; \
done ; \
The 'exit 1' part is to detect missing files -- I belive that all
errors will be detected at copy stage.
We explicitly remove stale .NRLIBS, so I do not think that stale
object file can splip past this check.
> I think, src/algebra/Makefile.in must be improved with respect to an
> earlier abort of a failing build. The 'for' loops in targets stamp-oboo3
> and stamp-bootstrap look suspicious to me.
>
> Waldek, do you see any quick fix for this? Perhaps adding a test whether
> X.NRLIB/X.o has indeed been created after compilation of X.spad?
>
I am affraid that there is no really quick and good fix. Adding
test for existence of result files would help, but there are
several places where we compile spad files so it would complicate
makefiles. And in some case we have to compile simultaneously
many files, so detection still would be late.
I plan to implement different solution: modify Spad compiler
so it exiits on errors. More precisely I think about adding
a new command (or maybe a new option to compile commad). So
to normal compile will work as is, but the new command will
exit on errors with exit status signaling failure. To do this
we need:
- implement exit with status (how to do this depends on
Lisp implementation, so we need separate code for each
Lisp flavour)
- add a new global variable (flag) '$ExitOnErrors' normally
set to false, but changed to true by the new compile
command (option)
- modify error reporting routines so that after printing
error message they check the flag and exit if requested
The whole thing is simple, but since there are many places
where something may go wrong it will take some time to
implement.
--
Waldek Hebisch
[email protected]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
