Also, move remaining "srfi" libraries to "srfi-lite-lib".
In principle, "base" should depend on "scheme-lib" and
"srfi-lite-lib", and a new "base2" package would represent the new,
smaller base. But I don't think the window has yet closed on
determining the initial "base" package.
The "srfi" libraries moved to "srfi-lite-lib", instead of "srfi-lib",
to avoid creating many extra dependencies on "srfi-lib" and all of its
dependencies. The SRFIs in "srfi-lite-lib" depend only on "base",
and they are used relatively widely.
original commit: d175c3949c
Also, move remaining "srfi" libraries to "srfi-lite-lib".
In principle, "base" should depend on "scheme-lib" and
"srfi-lite-lib", and a new "base2" package would represent the new,
smaller base. But I don't think the window has yet closed on
determining the initial "base" package.
The "srfi" libraries moved to "srfi-lite-lib", instead of "srfi-lib",
to avoid creating many extra dependencies on "srfi-lib" and all of its
dependencies. The SRFIs in "srfi-lite-lib" depend only on "base",
and they are used relatively widely.
The following expression would trigger an arity error:
(subst-all
(make-simple-substitution (list 'a 'z) (list (-val 3) (-val 5)))
(make-ListDots (make-F 'z) 'a))
Having `__VFP_FP__` defined does not mean that VFP instructions are
available; it just means that floating-point is native-endian.
According to
https://wiki.debian.org/ArmEabiPort
the absence of `__SOFTFP__` combined with the precense of `__VFP_FP__`
can mean VFP, though.
This rule supplements the old (but now less applicable) rule to
never add debugging-compiled files in the main installation's
"collects" directory.
Note that the new rule does not prevent compilation in
main-distribution packages that are linked, as in the development mode
set up by `make' in the Racet repository's top-level directory.
I think that's probably ok, since the intent of the check is mainly
just to not write to shared installation spaces, which shouldn't be
an issue for development mode.
