Changes are coming to the https://github.com/racket/racket repo.
Within a few days, when you `make` from the Git repo, you'll end up running Racket CS as `racket` (and DrRacket CS as `drracket`, etc.) instead of Racket BC. This does *not* mean that the snapshots or the release will immediately change to Racket CS, although it's part of a plan to get there. Even this part of the plan requires two steps. The first step will happen right away, and it's mostly about improving the Racket CS build process and removing the dependency of building Racket BC first: * The https://github.com/racket/ChezScheme repo will be included as a subtree of https://github.com/racket/racket. Combining the two repos makes it easier to keep them in sync for various purposes, such as designating releases or when a pull request needs to span the two repos. Git submodules are another possible approach to that problem, but both past experience and new experiments suggest that submodules will create problems. The subtree pattern still allows changes to be pulled from and backported to the ChezScheme repo. The ChezScheme repo's history will be preserved while merging it into the Racket repo, but boot files will be pruned from the history, so all of the commit IDs will change --- but the old commit IDs will be preserved as amendments to each commit message. The submodules already in the ChezScheme repo are also merged, but as squashed subtrees, because history and potential backporting are not really a concern there. * Racket CS will build directly without first building Racket BC. The key here is a new pb (portable bytecode) backend for Chez Scheme, where a single set of boot files work for all supported platforms, and those boot files can be used to build the native boot files on each platform. A single set of pb boot files is an alternative to the multiple sets of boot files (for a subset of supported platforms) that were originally included in the Chez Scheme repo. The new pb boot files are not added to the `racket` repo, however. They're checked into a different repo https://github.com/racket/pb and every revision will go into a fresh branch of that repo (i.e., no branch has history). This strategy works something like submodules, but managed more explicitly by the top-level makefile in the `racket` repo to avoid submodule pitfalls. The pb boot files will be included in a source bundle, so that the source can be built on any supported platform using only conventional tools (like `make`, a C compiler, etc.). Alternatively, Racket CS can be bootstrapped without pb boot files by running an old Racket --- at least v7.1, but not necessarily the same version as the one being built. In this sense, the pb boot files really aren't needed to recreate a build easily, so it's reasonable for them to be in a separate repository. * Schemified variants of the Racket-implemented layers of Racket CS will be checked into the repository. This is another component of building Racket CS directly. Layers like "thread", "io", and "expander" are implemented in Racket and compiled to Chez Scheme. Unlike boot files, the compiled ".scm" forms are human-readable and -editable, and they diff nicely: small changes to the source tend to create small changes in the ".scm" form. Also unlike boot files, they must be created by a similar Racket version, so all the traditional bootstrapping trickiness applies, mitigated only somewhat by the fact that the output is editable. They're not easily recreated for an old version (at least, without going through BC), so they make sense to check in. This first step will happen tomorrow, pending any objections or problems discovered before then. The second step is where `racket` starts meaning Racket CS. It will take some time (likely measured in days rather than hours or weeks), but it will be the more significant change if you're not actively developing Racket internals: * A `make` at the top level of a repo checkout will build Racket CS instead of Racket BC. The generated Racket CS executable will be `racket` by default, and a new `bc` target will create a Racket BC executable named `racketbc` by default. The `both` target will create `racket` and `racketbc`. An executable with a `bc` suffix will put ".zo" files in a subdirectory of "compiled", similar to the way that `racketcs` currently puts compiled files in a subdirectory, so the two variants can coexist in a build. * The "racket/src/racket" directory within the repo will move to "racket/src/bc/racket". Some sibling directories, like "gracket" and "foreign", probably also move into "bc" to clarify that they are specific to the BC build. We can take these steps without shifting the snapshot or release builds to Racket CS, but this will already be a big change for anyone working from the Git repo. Matthew -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20200728194813.2ce%40sirmail.smtp.cs.utah.edu.
