Currently, we have a nearly full copy of the rust-lang repo in here. This is undesirable for multiple reason. It makes the repo heavier than it needs to be, and brings a ton of code that is actually unreachable. Besides, we only have very light patches to libstd, and a ton of "new" code for the libstd::sys.
I think we should move to a patch-based system. The idea is, we would only store a single (or maybe a couple) .patch files in the repo, that would get applied by the build system to the rust-src component. cargo make qemu would have a new step, "fork-rust", that would cp -r the rust-src module into rust/, and apply the patchfiles on top of it. A new command, cargo make create-patch, would automatically re-create the patchfile by running diff rust/ $(rust-src location)
Several benefits:
It removes the current scenario where we have two sources of trust for the rust fork (sunriseos/rust and sunriseos/sunrise/rust). The fork could be kept to easily see the result of the patch, but be automatically updated through github actions, to prevent it from going out of sync.
Updating to latest nightly becomes a fairly obvious and simple business: Just update the patches to make them work. No need to mess around with branches or whatever.
Currently, we have a nearly full copy of the rust-lang repo in here. This is undesirable for multiple reason. It makes the repo heavier than it needs to be, and brings a ton of code that is actually unreachable. Besides, we only have very light patches to libstd, and a ton of "new" code for the
libstd::sys.I think we should move to a patch-based system. The idea is, we would only store a single (or maybe a couple)
.patchfiles in the repo, that would get applied by the build system to therust-srccomponent.cargo make qemuwould have a new step, "fork-rust", that wouldcp -rthe rust-src module into rust/, and apply the patchfiles on top of it. A new command,cargo make create-patch, would automatically re-create the patchfile by runningdiff rust/ $(rust-src location)Several benefits: