Ralf Hemmecke wrote:
> >> 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.
>
> Of course, the other plan to fix the SPAD compiler to exit on error
> would be the best solution, but I'd prefer to have a workaround now.
> In fact, I'd also like to continue a broken build after I've fixed the
> error. But that is certainly something for later.
>
> There are not too many places in src/algebra/Makefile.in where
> ${INTERPSYS} is called.
>
> For example in 'stamp-bootstrap' there is
>
> for A in ${SPADLIST} ; do \
> echo $${A}.NRLIB/$${A}.lsp: $${A}.spad >> boot.mak ; \
> echo -e '\techo ")compile" $$< | DAASE=./r7 ${INTERPSYS}' \
> >> boot.mak ; \
> echo >> boot.mak ; \
> done ; \
> ${MAKE} -f boot.mak main-bootstrap ; \
>
> That could become
>
> for A in ${SPADLIST} ; do \
> echo $${A}.NRLIB/$${A}.lsp: $${A}.spad >> boot.mak ; \
> echo -e '\techo ")compile" $$< | DAASE=./r7 ${INTERPSYS}' \
> >> boot.mak ; \
> echo -e '\ttest -f $@' >> boot.mak ; \
> echo >> boot.mak ; \
> done ; \
> ${MAKE} -f boot.mak main-bootstrap && \
>
> (I've added the 'test -f' line and replaced ';' by '&&' after the
> ${MAKE} command.)
>
> Interestingly, you have
>
> for A in ${CATLIST} ${DOMLIST} ; do \
> echo ')compile "'$$A'.spad"' >> oboo3.input ; \
> done; \
> ( echo ')read "oboo3.input"' | \
> DAASE=./r7 ${INTERPSYS} ) || exit 1 ; \
>
> in the stamp-oboo3 target. That already looks as if ${INTERPSYS} exits
> with an error code if something goes wrong.
I think that compiler exits on _some_ errors, but mostly the exit
part waits for future improvements.
> What I don't understand is:
> why are all the )compile commands in oboo3.input? Isn't
>
> for A in X Y ; do \
> echo ')compile "'$$A'.spad"' ; \
> done | DAASE=./r8 ${INTERPSYS} ; \
>
> equivalent to
>
> for A in X Y ; do \
> echo ')compile "'$$A'.spad"' | DAASE=./r8 ${INTERPSYS} ; \
> done
>
No. The first version uses declaration from earlier files to
compile later ones. You could try to approximate the first
version by dumping databases after each step, but I am affraid
it would still not be fully equvalent. Moreover, dumping databases
would be a performance killer.
> ? Of course the second could more easily be modified for early aborting
> the build process on failure.
>
> So if you want, I could create a patch, but first I have to understand
> why the commands are as they are now. It's still not completely clear
> where the order exactly of the compilation of the spad files is
> important, i.e. where I would have to create linear dependencies for the
> generated .mak file.
>
During early bootstrap it is essential to do some stages in a single
image, also order is essential. After 'stamp-oboo3' order is
much more relaxed (the main work is done in a separate makefile
which may be fully parallel). However, there are some dependencies,
and for example guessing package must be compiled in single image
In principle guessing package can be included in normal bootstrap
sequence but now it serves as an example how to add multidomain
collection without modifying main bootstrap sequence.
I would not touch stages up to (including) 'stamp-oboo3' -- they
are sequential and errors should be detected just after failing stage.
Files in BADSPADS list either fail or generate bad code during
main compilation, so we need to compile them second time. One
could probably eliminate failures adding proper dependencies to
generated makefile (boot.mak), but ATM the ones with wrong
code look unavoidable (wrong code is due to missing datebase
entries and we need to compile all files to get full database).
--
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
-~----------~----~----~----~------~----~------~--~---
