Dag-Erling Smorgrav <des@...> writes:
> The first failure I encountered was that for some mysterious reason,
> src/runtime/bsd-os.c includes <sys/proc.h> which in FreeBSD 5 at least
> defines a 'struct thread' which conflicts with SBCL's own. Removing
> the #include is perfectly safe as it isn't needed at all.
Right. This was reported a while ago, but our freeze process caught
up with us, so this wasn't fixed until sbcl-0.8.0.1. Do you happen to
know if it's likewise safe to remove the #include on OpenBSD, which
will be compiling the same file?
> The second failure occurs much further down the road, while compiling
This compilation failure has been fixed in the CVS, thanks. However,
I should note that while failure to compile one of the contributed
systems is not ideal, neither should it hold back distribution of sbcl
proper; the install.sh script tests for whether a contrib has
successfully passed its regression tests, and does not install it if
> Another problem is that make.sh doesn't seem to return a non-zero exit
> code even when the build fails, which really confuses the ports
> system. The problem is most likely in make-*.sh and not in make.sh
> itself since it does check their return codes... Running them with
> 'sh -e' instead of plain 'sh' might help, but it may also cause false
> negatives if the scripts use constructs like '[ condition ] &&
> statement' (which must be rewritten to '[ ! condition ] || statement'
> to pass muster with -e)
Thanks for the suggestion; while being able to catch all cases in all
conditions is probably beyond the bounds of possibility (multiply N
lisp bootstrap hosts by M mostly-Bourneish-sh by X versions of gcc) it
ought to be possible to catch the most egregious errors, maybe by
comparing modification times on certain key files or directories.
> If it's not already on your todo list, I'd also suggest implementing
> some kind of dependency tracking so it doesn't take bloody ages to
> restart a build after fixing an error... at least for me as I am
> still stuck in the 20th century, hardware-wise...
You are not the only one.
However, because of the way that Lisp works, the dependencies in
lispland would look much like
"file2" :depends-on "file1"
"file3" :depends-on "file2"
there are shortcuts possible, but they're not ideal unless you know
what you're doing (and even then, it's easy to be tripped up: witness
the two unbuildable patches that I submitted last week, caused by the
fact that I was taking too many shortcuts).
However, the coarse-grained dependencies at the level of the make-*.sh
scripts is mostly reliable; if you have successfully made it through
make-host-1.sh, you probably don't have to do it again (unless you
change internal compiler data structures, in which case you would have
to start from the beginning). Some manual setting of environment
variables might be necessary, but it's quite reasonable to just do
GNUMAKE=gmake sh ./make-target-contrib.sh
(There is another issue specific to contrib; systems get built
multiple times... we're working on that one.)
Thanks again for the reports,
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)