>> 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.
Sorry. Yes, you are right.
>> 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.)
Then there are places like
for A in ${EXTRASPADS} ; do \
echo ')compile "'$$A'.spad"' ; \
done | DAASE=./r8 ${INTERPSYS} ; \
where I don't see a reasone to call them in one ${INTERPSYS} call,
except that files have to be compiled in the order given via ${EXTRASPADS}.
Shouldn't that better work like the boot.mak case above with adding a
dependency
file_n: file_(n-1)
in a corresponding boot2.mak? (If order really matters.)
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. 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
? 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.
Ralf
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
