From: Junio C Hamano <hidden> Date: 2025-10-28 04:15:54
"brian m. carlson" [off-list ref] writes:
On 2025-10-27 at 20:35:59, Ezekiel Newren wrote:
quoted
On Fri, Oct 24, 2025 at 12:37 AM Patrick Steinhardt [off-list ref] wrote:
quoted
quoted
cbindgen is a Rust crate and it should be specified in the Cargo.toml
under [build-dependencies] block.
What is the benefit for us? The generated code is not a dependency of
the Rust code, and neither do we use it via "build.rs". And if we use
cbindgen via "Cargo.toml" we'd be forced to build it first, which slows
down our CI jobs.
Please let me know in case I miss any reasons to have it in our build
dependencies instead.
You're targeting a very old version of Rust (1.49). I'm not even sure
that cbindgen will work with a version that old, but if it does then
we should use it in build.rs to make sure we're not using any features
of cbindgen that aren't available until later versions.
...
For instance, I'm using Debian unstable with a system cbindgen 0.27.0.
This requires Rust 1.70 or newer. If I use rustup to test my code on
Rust 1.49, then the code won't compile for me.
Have we even agreed on which Rust version we would aim for? With
BreakingChanges.adoc We have agreed to make some version of Rust
mandatory by the time we hit Git 3.0 but IIRC, there isn't anything
written down except for an old message from you
https://lore.kernel.org/git/ZZ9K1CVBKdij4tG0@tapette.crustytoothpaste.net/
that expressed your preference to support the version of Rust in the
latest Debian stable plus the version in Debian's oldstable until
the latest stable has been out for a year, which nobody responded
to, so we cannot quite say that is the consensus of the community,
yet.
Given that the stable/trixie was released on August 9th, 2025, we
still need to go by oldstable/bookworm, which has Rust 1.63, if
people agree that your rule to decide the floor version is sensible
(which I would say is OK).
On Mon, Oct 27, 2025 at 10:15 PM Junio C Hamano [off-list ref] wrote:
Given that the stable/trixie was released on August 9th, 2025, we
still need to go by oldstable/bookworm, which has Rust 1.63, if
people agree that your rule to decide the floor version is sensible
(which I would say is OK).
I think that 1.63 should be the minimum that Git supports. I think
1.49 is way too old. It was a bit of a struggle to get cbindgen to
work with 1.63, and I don't know if it will work at all with 1.49.
From: Patrick Steinhardt <hidden> Date: 2025-10-30 09:50:37
On Tue, Oct 28, 2025 at 01:11:53PM -0600, Ezekiel Newren wrote:
On Mon, Oct 27, 2025 at 10:15 PM Junio C Hamano [off-list ref] wrote:
quoted
Given that the stable/trixie was released on August 9th, 2025, we
still need to go by oldstable/bookworm, which has Rust 1.63, if
people agree that your rule to decide the floor version is sensible
(which I would say is OK).
I think that 1.63 should be the minimum that Git supports. I think
1.49 is way too old. It was a bit of a struggle to get cbindgen to
work with 1.63, and I don't know if it will work at all with 1.49.
I think cbindgen 0.20 should support Rust 1.49, but I'm honestly not
sure about this. They simply didn't specify a MSRV before 0.21, and in
0.21 they bumped to require Rust 1.57.
Patrick
From: Patrick Steinhardt <hidden> Date: 2025-10-30 09:50:43
On Mon, Oct 27, 2025 at 09:15:51PM -0700, Junio C Hamano wrote:
"brian m. carlson" [off-list ref] writes:
quoted
On 2025-10-27 at 20:35:59, Ezekiel Newren wrote:
quoted
On Fri, Oct 24, 2025 at 12:37 AM Patrick Steinhardt [off-list ref] wrote:
quoted
quoted
cbindgen is a Rust crate and it should be specified in the Cargo.toml
under [build-dependencies] block.
What is the benefit for us? The generated code is not a dependency of
the Rust code, and neither do we use it via "build.rs". And if we use
cbindgen via "Cargo.toml" we'd be forced to build it first, which slows
down our CI jobs.
Please let me know in case I miss any reasons to have it in our build
dependencies instead.
You're targeting a very old version of Rust (1.49). I'm not even sure
that cbindgen will work with a version that old, but if it does then
we should use it in build.rs to make sure we're not using any features
of cbindgen that aren't available until later versions.
...
For instance, I'm using Debian unstable with a system cbindgen 0.27.0.
This requires Rust 1.70 or newer. If I use rustup to test my code on
Rust 1.49, then the code won't compile for me.
Have we even agreed on which Rust version we would aim for? With
BreakingChanges.adoc We have agreed to make some version of Rust
mandatory by the time we hit Git 3.0 but IIRC, there isn't anything
written down except for an old message from you
https://lore.kernel.org/git/ZZ9K1CVBKdij4tG0@tapette.crustytoothpaste.net/
that expressed your preference to support the version of Rust in the
latest Debian stable plus the version in Debian's oldstable until
the latest stable has been out for a year, which nobody responded
to, so we cannot quite say that is the consensus of the community,
yet.
For now that Rust version is 1.49, and that's enforced by our CI. The
reason for this specific version is that it's the target version for the
gcc-rs folks, so it may help currently-unsupported platforms to get
support earlier.
But I made clear in past patch series that if we have strong reasons to
use a more recent version of Rust, then we should update. I mostly
wanted us to do this intentionally than picking any random Rust version
and saying that "this is it now".
Patrick
From: brian m. carlson <hidden> Date: 2025-10-30 21:40:03
On 2025-10-30 at 09:50:36, Patrick Steinhardt wrote:
For now that Rust version is 1.49, and that's enforced by our CI. The
reason for this specific version is that it's the target version for the
gcc-rs folks, so it may help currently-unsupported platforms to get
support earlier.
As I mentioned a couple of times, gcc-rs uses the standard library of
Rust 1.49 since that's what it's targeting, and as a result it will not
support any platforms that Rust 1.49 didn't support since there isn't
standard library support for those platforms in that version. It's like
trying to use a 2009 version of glibc and expecting it to work on
RISC-V, which was released in 2010—it simply won't.
That's why I was very clear at the Contributor's Summit that the message
we must send to platforms that do not have Rust is that they need to
port LLVM and target Rust that way, since that is the surest path to
success and to being able to get the necessary standard library changes
for things to work properly. gcc-rs may be a viable solution in the
future, but it is not now, and absent substantial advances and an
order-of-magnitude faster development, it is unlikely to meet that
standard in time for Git 3.0.
So given that, I would propose that we target Rust 1.63 in conjunction
with my proposal. I can send a patch to that effect later on.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
From: Patrick Steinhardt <hidden> Date: 2025-10-31 06:05:42
On Thu, Oct 30, 2025 at 09:40:01PM +0000, brian m. carlson wrote:
On 2025-10-30 at 09:50:36, Patrick Steinhardt wrote:
quoted
For now that Rust version is 1.49, and that's enforced by our CI. The
reason for this specific version is that it's the target version for the
gcc-rs folks, so it may help currently-unsupported platforms to get
support earlier.
As I mentioned a couple of times, gcc-rs uses the standard library of
Rust 1.49 since that's what it's targeting, and as a result it will not
support any platforms that Rust 1.49 didn't support since there isn't
standard library support for those platforms in that version. It's like
trying to use a 2009 version of glibc and expecting it to work on
RISC-V, which was released in 2010—it simply won't.
That's why I was very clear at the Contributor's Summit that the message
we must send to platforms that do not have Rust is that they need to
port LLVM and target Rust that way, since that is the surest path to
success and to being able to get the necessary standard library changes
for things to work properly. gcc-rs may be a viable solution in the
future, but it is not now, and absent substantial advances and an
order-of-magnitude faster development, it is unlikely to meet that
standard in time for Git 3.0.
It seems like there is good progress in gccrs, and it seems like the
speed is picking up a bit. They also recently said that it shouldn't be
that complicated to move to 1.80 once the 1.49 baseline is implemented,
so that makes me more amenable towards picking a more recent Rust version
[1].
So given that, I would propose that we target Rust 1.63 in conjunction
with my proposal. I can send a patch to that effect later on.
I might've missed it, but why 1.63 in particular? Happy to defer the
discussion until you post the patch though. I mostly want to make sure
that we pick the version with intent.
Thanks!
Patrick
[1]: https://lwn.net/Articles/1040197/