As it turns out, some of the load/compile time set up the package does
doesn't work in ECL for unknown reasons at the moment. Executables using
closure-* will crash after starting up:
;;; Checking for wide character support... WARNING: Lisp implementation doesn't use UTF-16, but accepts surrogate code points.
yes, using code points.
;;; Building Closure with CHARACTER RUNES
Condition of type: SIMPLE-ERROR
Invalid relative pathname #P"package.lisp" for component ("closure-common" "package")
Change-Id: I4b4bf96835a39696884ec6fea9c249fdeb53c853
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12863
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
This seems to be unnecessary: It doesn't muffle any SBCL warnings that
affect a current version and does nothing special otherwise.
Change-Id: I36efde761fc95d9df735f29d2eb369c6b61853c9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3486
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
This one requires a bit of jumping through hoops. Patching the dtd /
catalog lookup is quite straightforward and similar to cxml, but the
CLOSURE-HTML:*html-dtd* variable gives us a bit of trouble: It is
defined quite late in `html-parser.lisp`, but files that need to be
built first already reference it. SBCL has apparently decided to be
particular about this and emits a `WARNING` (!) condition for this
which is also worthy of `failure-p` of `compile-file` being true,
so that `buildLisp` will abort compilation. We workaround this issue
by injecting an extra source file which `defvar`s the desired symbol.
A similar issue exists with `dump-dtd` which references
`CL-USER:*HTML-DTD*` for some reason. Since this is a helper intended
for development (?) and not exported we just throw it away via a
patch.
Change-Id: Ic0f92815a21f3793925c49a70a72f4a86791efe4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3263
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
