`makefiles/boot.zuo`'s `main` calls `cross-build-boot` incorrectly
LiberalArtist opened this issue · 3 comments
In 10d59cc#diff-8adebbb27a9540dc754a57375e77d019b00c55580b6574f5ec1b89d58a3e17af, cross-build-boot gained an xpatch? argument, but boot.zuo's main submodule is still calling it with 10 arguments instead of 11:
Lines 14 to 20 in 57f92bb
In the scenarios I've tried, it's worked to just add #t after '("all"), but I'm not sure if that's correct in general.
Should this main submodule be here at all? I can't remember the reason for boot.zuo to be used directly. I wonder whether it was experiment that turned out not to be useful — or maybe it's useful, and I forgot how it's used.
According to https://racket.discourse.group/t/chez-for-architectures-without-native-backends/950/15, I'd read about it in:
Lines 85 to 93 in 2b39576
The link in my post was to Racket's release branch, and thus is broken, but it looks like you added it in 5cf80b7 the day after you wrote the comment above the one I linked to, and you removed that text from the document (but did not change boot.zuo) in 1152c60.
It fits especially well with the use in Guix, when, having already built our native chez-scheme package (and having discarded its build directory), we subsequently want to build bootfiles for some other machine type. The way the Guix packaging is set organized (at least, the best way I've found to organize it so far), we first build a Guix package containing bootfiles, then supply that as an input to the Guix package that does the rest of the Chez Scheme build. That lets us share the package definition with relatively few conditionals and overrides among native and cross-compiled (with make kernel) packages that might have gotten their bootfiles through various different strategies: rktboot, build.zuo, formerly pre-built bootfiles that we couldn't bootstrap, and, as of earlier today in my fork, re.boot for Chez 10.
On the other hand, a number of new build modes have emerged since then, and maybe one of them would work well enough for our use-case. Maybe cross.boot is the one to look at? It was convenient not to have to call configure, but I think I figured out a way to do it with relatively little fuss for re.boot.
Thanks for digging through the history here! That seems to confirm that it was an intermediate design that was meant to be replaced in later, but the old entry point as a main submodule was never removed. As always, if the other documented build modes can work, that seems better than trying to maintain more modes.