From: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Patrick Steinhardt <ps@pks.im>,
James Le Cuirot <chewi@gentoo.org>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: [PATCH v3 0/2] Use Rust in the Windows CI jobs
Date: Sun, 13 Sep 2026 10:31:14 +0000 [thread overview]
Message-ID: <pull.2213.v3.git.1789295476.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.2213.git.1788272509.gitgitgadget@gmail.com>
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
--
gitgitgadget
next prev parent reply other threads:[~2026-09-13 10:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 14:21 [PATCH 0/2] Use Rust in the Windows CI jobs Johannes Schindelin via GitGitGadget
2026-09-01 14:21 ` [PATCH 1/2] rust: pick a GCC-compatible Cargo target under MSYS2/MinGW Johannes Schindelin via GitGitGadget
2026-09-02 6:25 ` Junio C Hamano
2026-09-11 12:25 ` Johannes Schindelin
2026-09-01 14:21 ` [PATCH 2/2] ci(windows): build with Rust Johannes Schindelin via GitGitGadget
2026-09-11 19:08 ` [PATCH v2 0/2] Use Rust in the Windows CI jobs Johannes Schindelin via GitGitGadget
2026-09-11 19:08 ` [PATCH v2 1/2] rust: pick a GCC-compatible Cargo target under MSYS2/MinGW Johannes Schindelin via GitGitGadget
2026-09-11 21:09 ` Junio C Hamano
2026-09-11 22:26 ` James Le Cuirot
2026-09-13 10:30 ` Johannes Schindelin
2026-09-11 19:08 ` [PATCH v2 2/2] ci(windows): build with Rust Johannes Schindelin via GitGitGadget
2026-09-13 10:31 ` Johannes Schindelin via GitGitGadget [this message]
2026-09-13 10:31 ` [PATCH v3 1/2] rust: pick a GCC-compatible Cargo target under MSYS2/MinGW Johannes Schindelin via GitGitGadget
2026-09-13 10:31 ` [PATCH v3 2/2] ci(windows): build with Rust Johannes Schindelin via GitGitGadget
2026-09-13 15:57 ` [PATCH v4 0/2] Use Rust in the Windows CI jobs Johannes Schindelin via GitGitGadget
2026-09-13 15:57 ` [PATCH v4 1/2] rust: pick a GCC-compatible Cargo target under MSYS2/MinGW Johannes Schindelin via GitGitGadget
2026-09-13 15:57 ` [PATCH v4 2/2] ci(windows): build with Rust Johannes Schindelin via GitGitGadget
2026-09-13 22:52 ` [PATCH v4 0/2] Use Rust in the Windows CI jobs Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pull.2213.v3.git.1789295476.gitgitgadget@gmail.com \
--to=gitgitgadget@gmail.com \
--cc=chewi@gentoo.org \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.