With v2.55.0, Git requires Rust by default, with an opt-out that is intended to be dropped in one of the next versions.
Due to the special circumstances in the Windows part of the CI builds, each Windows build job first downloads a "minimal Git for Windows SDK" that contains the GCC toolchain required to build and test Git. As a consequence, brian m. carlson opted out of Rust in Git's CI definition in 32d5b905909e (Enable Rust by default, 2026-04-09).
So: How could we stop opting out? Notably, Rust is not part of that minimal
Git for Windows SDK, and including it would more than double that payload,
which I consider prohibitive. Yet including Rust in the minimal Git for
Windows SDK is not actually necessary, at least not for the GitHub workflow:
The runners on which this workflow is defined to run come with Rust
pre-installed.
Granted, this Rust installation is configured to target the Windows-native C compiler, Visual C. To accommodate for the Windows CI job building with GCC, this patch series adds a step to the workflow that ensures that the needed Rust bits are installed and configured.
RFH: I haven't been able to confirm that GitLab's Windows runners come with
Rust preinstalled,
https://docs.gitlab.com/ci/runners/hosted_runners/windows/#available-runtimes
did not clarify that for me. Patrick (or anyone else with access to GitLab
CI), could you see whether this patch series builds on
saas-windows-medium-amd64 without need for further changes?
Changes since v1:
* The inconsistency pointed out by Junio, that UCRT64 was once marked as
using clang and once as using gcc was fixed by clarifying that UCRT64
uses GCC.
Johannes Schindelin (2):
rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
ci(windows): build with Rust
.github/workflows/main.yml | 24 ++++++++++++++++++++++++
Makefile | 2 +-
ci/lib.sh | 3 ---
config.mak.uname | 25 ++++++++++++++++++++++++-
4 files changed, 49 insertions(+), 5 deletions(-)
base-commit: f4742f3165d096130c39a71feb26374da37620f2
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2213%2Fdscho%2Fuse-rust-in-windows-ci-builds-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2213/dscho/use-rust-in-windows-ci-builds-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/2213
Range-diff vs v2:
1: 6567eceb32 ! 1: b70b001f62 rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
@@ Commit message
When Git is built under MSYS2/MinGW with Rust support enabled, the
Makefile expects `cargo build` to drop a `target/release/libgitcore.a`
- that is linkable by the same MinGW GCC used for every other object.
- With Rust installed via `rustup` (the way it ships on the
- GitHub-hosted `windows-2022` and `windows-11-arm` runners that build
- microsoft/git), the default toolchain targets the MSVC ABI; cargo
- then writes `target/release/gitcore.lib` instead, which the MinGW
- `ld.exe` cannot consume:
+ that is linkable by the same MinGW GCC used for every other object. With
+ Rust installed via `rustup` (the way it ships on the GitHub-hosted
+ `windows-2022` and `windows-11-arm` runners that build git/git and its
+ forks), the default toolchain targets the MSVC ABI; cargo then writes
+ `target/release/gitcore.lib` instead, which the MinGW `ld.exe` cannot
+ consume:
LINK git-shell.exe
D:\git-sdk-64-minimal\mingw64\bin/ld.exe: cannot find target/release/libgitcore.a: No such file or directory
collect2.exe: error: ld returned 1 exit status
- See https://github.com/microsoft/git/actions/runs/27341625000 for the
- full log.
+ See https://github.com/microsoft/git/actions/runs/27341625000 for a
+ full example log.
- Let's define the correct target. Re-use (and fix) the existing
- `HOST_CPU` variable for that purpose. Avoid relying on environment
- variables that are simply not defined in Git for Windows' minimal SDK
- that Git uses in its CI runs.
+ Let's define the correct target, using the `CARGO_BUILD_TARGET` variable
+ that will be picked up by Rust, see
+ https://dirname.github.io/rust-std-doc/cargo/reference/environment-variables.html#:~:text=CARGO%5FBUILD%5FTARGET
+
+ Re-use (and fix) the existing `HOST_CPU` variable to determine the
+ correct value. Avoid relying on environment variables that are simply
+ not defined in Git for Windows' minimal SDK that Git uses in its CI
+ runs.
+
+ Note that this _still_ requires an explicit `--target` option to be
+ picked up in the way Git's build process calls cargo.
Assisted-by: Claude Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@@ Makefile: RUST_LIB_NAME = gitcore.lib
RUST_LIB_NAME = libgitcore.a
endif
-RUST_LIB = target/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
-+RUST_LIB = target$(if $(CARGO_TARGET),/$(CARGO_TARGET))/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
++RUST_LIB = target$(if $(CARGO_BUILD_TARGET),/$(CARGO_BUILD_TARGET))/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
endif
GITLIBS = common-main.o $(LIB_FILE)
-@@ Makefile: endif
- ifndef DEBUG
- CARGO_ARGS += --release
- endif
-+CARGO_ARGS += $(if $(CARGO_TARGET),--target $(CARGO_TARGET))
-
- # For the 'sparse' target
- SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
## config.mak.uname ##
@@ config.mak.uname: ifeq ($(uname_S),MINGW)
@@ config.mak.uname: ifeq ($(uname_S),MINGW)
+ HOST_CPU = x86_64
+ endif
+ ifneq (,$(filter CLANG%, $(MSYSTEM)))
-+ CARGO_TARGET = $(HOST_CPU)-pc-windows-gnullvm
++ CARGO_BUILD_TARGET = $(HOST_CPU)-pc-windows-gnullvm
+ else
-+ CARGO_TARGET = $(HOST_CPU)-pc-windows-gnu
++ CARGO_BUILD_TARGET = $(HOST_CPU)-pc-windows-gnu
+ endif
++ export CARGO_BUILD_TARGET
+
BASIC_LDFLAGS += -Wl,--pic-executable
COMPAT_CFLAGS += -DDETECT_MSYS_TTY \
2: 07415393e5 = 2: 76469029ff ci(windows): build with Rust