Rust repository is large (as it should be) and building it requires gigabytes of hard drive, bandwidth, hours of cpu, ... Which make it hard for contributors, specially those who want to make an small, one-time contribution.
Gitpod is an open source cloud environment for developing. If rust has enough infrastructure, It can build gitpod images in CI and developers can start with a compiled, tested development environment in some seconds.
Some work is already being done to allow for reuse of certain CI artifacts instead of building them manually. For example you can now use a pre-built LLVM. @jyn514 is also added an option to use a pre-built rustc to build rustdoc with: Allow building rustdoc without first building rustc (MVP) by jyn514 · Pull Request #79540 · rust-lang/rust · GitHub Apart from these things there isn't much more compile times that can be saved with something like Gitpod. If you change the compiler for example, you may also need to compile the compiler from scratch using itself.
./x.py setup also provides a way to set compilation defaults optimized for for example changing the standard library. This avoids building the compiler by default I think.
This avoids building the compiler by default I think.
Hmm, "by default" is a tricky metric - x.py setup library sets the default stage to 0, so x.py build library/std no longer builds the compiler by default, but x.py build will still build the compiler and all tools. At some point I want to add different entry points for x.py, so it can change the default behavior or give hard errors if you try to do something that doesn't make sense in context: Add different entry points for x.py · Issue #396 · rust-lang/compiler-team · GitHub
Apart from these things there isn't much more compile times that can be saved with something like Gitpod. If you change the compiler for example, you may also need to compile the compiler from scratch using itself.
Yup I agree with this - the only way I can see pre-built images being useful is having a pre-built incremental cache or something? That's a lot of CI time though, since currently we don't use incremental for CI artifacts, and it also doesn't help with full builds (which I know at least @Mark_Simulacrum says he uses almost exclusively). It would also be a truly enormous image, I think incremental caches use about 25-30 GB of disk space right now.
Isn't second time compiles easier? I thought it will only need to compile changed modules and reuse other parts. If it is not the case, benefit of gitpod will be just saving hard disk and bandwidth and compile time still suffers.
That does not matter for users, because they only work with a vscode-like editor in their browser and files are on the cloud.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.