Proposal
Rustup provides an OS-agnostic and easy-to-setup environment to compile rust programs, providing a smooth and simple out-of-the-box experience for building and using rust programs.
However that smooth experience is broken for any project doing web development or need https support, because they would require a C compiler toolchain and assembler to be installed and it is not bundled in rustup, users have to resort to OS-agnostic way to install it and that can range from relatively simple (apt-get/yum on linux) or requiring to do a whole msvc/Cygwin/wsl setup on windows.
With a clang compiler and llvm-ar bundled, cc can simply check for their availability and use them instead of throwing an error with a long log and ask users to parse them, google it and install it, like the C/C++ experience.
It would also enable work on zig-cc like out-of-the-box smooth cross compilation, when users to try build *-unknown-linux-musl on debian/ubuntu even when they have installed build-essentials, they are often thrown off by the strange error and have to google to understand what the heck is going on.
With clang shipped with rustup, we could add zig-cc like logic to cc while bundling the required headers/musl libc with rustup to provide a smooth out-of-the-box cross compilation, just like how we have smooth cross compilation for pure rust code, that would truly make cross compilation feels seem-less for project that needs to pull in C/C++ codebase, basically anything doing https and compression.
Having clang and llvm-ar shipped with rustup also has the benefit of easy cross language LTO, though this is not the main focus of this proposal, merely a by-product.
Finally, as the maintainer of cc, we have a very complex logic for looking for C compiler and ar and guessing their vendor (gcc vs clang vs msvc vs clang-cl), with clang and llvm-ar shipped with rustup we can have a sane default that we knows the vendor, and we know it is immutable (can be upgraded, but you can't suddenly replace it with the same version but produce slightly different output), so it'd be possible to cache our is_flag_supported logic (yes we need to call the compiler for each flag we've asked to check, and that is cached in cc::Build, every time we re-run the build script or for another crate's build script we have to re-run them), plus maybe we can also cache more stuff across crates in target, or more global caching like sccache, but simpler since we know the bundled clang is immutable we can do simpler caching.
Previous zulip discussion: https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/31
Related issue: rust-lang/rust#56371
Mentors or Reviewers
cc @joshtriplett
Process
The main points of the Major Change Process are as follows:
You can read more about Major Change Proposals on forge.
Proposal
Rustup provides an OS-agnostic and easy-to-setup environment to compile rust programs, providing a smooth and simple out-of-the-box experience for building and using rust programs.
However that smooth experience is broken for any project doing web development or need https support, because they would require a C compiler toolchain and assembler to be installed and it is not bundled in rustup, users have to resort to OS-agnostic way to install it and that can range from relatively simple (apt-get/yum on linux) or requiring to do a whole msvc/Cygwin/wsl setup on windows.
With a clang compiler and llvm-ar bundled, cc can simply check for their availability and use them instead of throwing an error with a long log and ask users to parse them, google it and install it, like the C/C++ experience.
It would also enable work on zig-cc like out-of-the-box smooth cross compilation, when users to try build *-unknown-linux-musl on debian/ubuntu even when they have installed build-essentials, they are often thrown off by the strange error and have to google to understand what the heck is going on.
With clang shipped with rustup, we could add zig-cc like logic to cc while bundling the required headers/musl libc with rustup to provide a smooth out-of-the-box cross compilation, just like how we have smooth cross compilation for pure rust code, that would truly make cross compilation feels seem-less for project that needs to pull in C/C++ codebase, basically anything doing https and compression.
Having clang and llvm-ar shipped with rustup also has the benefit of easy cross language LTO, though this is not the main focus of this proposal, merely a by-product.
Finally, as the maintainer of cc, we have a very complex logic for looking for C compiler and ar and guessing their vendor (gcc vs clang vs msvc vs clang-cl), with clang and llvm-ar shipped with rustup we can have a sane default that we knows the vendor, and we know it is immutable (can be upgraded, but you can't suddenly replace it with the same version but produce slightly different output), so it'd be possible to cache our is_flag_supported logic (yes we need to call the compiler for each flag we've asked to check, and that is cached in
cc::Build, every time we re-run the build script or for another crate's build script we have to re-run them), plus maybe we can also cache more stuff across crates intarget, or more global caching like sccache, but simpler since we know the bundled clang is immutable we can do simpler caching.Previous zulip discussion: https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/31
Related issue: rust-lang/rust#56371
Mentors or Reviewers
cc @joshtriplett
Process
The main points of the Major Change Process are as follows:
@rustbot secondor kickoff a team FCP with@rfcbot fcp $RESOLUTION.You can read more about Major Change Proposals on forge.