which happens to be #+win32 and exposed a bug that a no-longer-needed allowance
for warnings caused it to exit with success despite a missing BASE-CHAR-P, and
also that there was also a pre-existing warning in stream.lisp if #-sb-unicode.
and don't redirect *stdout* and *stderr* if -j1.
You can specify more than one target, and they will follow one another
with no chance of overlap since it's sequential. This should give more-or-less
the same behavior as the deleted crossbuild-runner/build-all.sh script.
We can add a few more indicators of where each build starts,
but this is probably adequate for now.
I'm starting to think that make-host-2 might need to suppress the MEMBER
transform if a constant list has a NIL, because the address of NIL is
sensitive to static-space-start, necessitating xperfecthash entries
for each choice. Nonetheles, gathering an exhaustive list of known good
configurations to test isn't in itself an unreasonable thing.
* Merge xperfecthash file diffs back into the main file
* Rather than hardwiring the choice of OS in pass-1.lisp, put the choice
in the configuration params. Unfortunately stuff-groveled-from-headers
may need to exist in different incarnations due to package issues.
Neither make-all-targets.sh nor crossbuild-runner/build-all.sh could
do everything deisired. build-all.sh could incorporate changes to xperfecthash
and xfloat-math into the revison-controlled files, but could not use >1 host
CPU (via "make -j") whereas in contrast, make-all-targets could utilize >1 CPU
but could not merge diffs into xperfecthash or or xfloat-math.
This new script can, in theory (i.e. not yet), merge target-specific journal
updates into the git-controlled files, while also using N CPUs.
It also corrects the defect of pass-2.lisp that it never wrote .core artifacts,
causing Make to re-run when it need not. Additionally, since Makefile is now
autogenerated we can insert approximate dependencies - in so far as it would
select the same subset of build-order.lisp-expr as would an ordinary build.
Also we gain the ability to specify more than one set of *FEATURES* to be
built for a given architecture. It simply needs a distinct "config name".
