From: Junio C Hamano Date: Sat, 01 Nov 2025 11:18:33 GMT Subject: Re: [PATCH 10/14] rust: add a build.rs script for tests Message-ID: In-Reply-To: Ezekiel Newren writes: >> Mostly flexibility. If we do not value it, then that is OK, though. >> >> And personally I would have to say that "meson rolled everything >> into a single library archive" is a bad excuse---whatever came later >> doing things differently from the incumbent has to have a good reason >> to do things differently, or it is a regression. > > I don't understand why "Simplify Cargo's job of linking with the build > systems of Makefile and Meson" Isn't a good enough reason by itself. Was that the way it was sold, though? The motivation is to simplify Rust's job of linking against the C code by requiring it to only link against a single static library (libgit.a). was how the original cover letter sold the change. In addition, in a later thread, I saw this: Like the previous two commits; This one continues the effort to get the Rust compiler to link against libgit.a. Meson already includes the reftable in its libgit.a, but Makefile does not. It led me into (incorrectly) thinking that Rust toolchain you are using for your series becomes very cumbersome, if not impossible, to use, if we try to have it use more than one library. My job as the project lead would have been to decide if maintaining the separation of three independent libraries was worth the hassle. In other words, I read it as "We have to do with a single library, due to limitations of Rust build infrastructure, and that is why we are merging logically three separate libraries into one in the build structure in the Makefile. Meson based build happens to already roll everything into one library, so we do not have to do anything extra to implement this workaround for Rust. Only Makefile side needs this change." If I knew that dealing with just one library was not a requirement placed by Rust (and apparently, what brian did in the series under discussion shows that it is not), I would have instead suggested to fix the Meson based build procedure, as I do agree with the idea of "simplifying" to avoid having to deal with 1 with Meson while 3 with Makefile. But I would have suggested to link the same set of three libraries on both sides. The fact I was (mis)lead into thinking that the only way to do so is to roll objects from three logically independent libraries into one (due to limitation in building Rust part of the code), when the other way, namely, to keep them separate also in Meson based builds, was also perfectly adequate because there is no such limitation placed by Rust, is mostly what makes me react unnecessarily strongly. Yes, I am upset. When there is no strong reason to be different for a newly introduced thing (that is, Meson relative to Makefile), it should avoid being different to avoid breaking expectations (e.g., we'd have this and that .a files left in the build directory to link with objects to produce "git"). So "I do not understand why keeping three is good" is not an argument. The Meson based build series needed to justify itself why rolling everything into one library was a good idea, but it seems nobody noticed the distinction back then when it was introduced, and you do not have to be retroactively defending that mistake now. The same about position independent code generation (I do not know if it hurts performance very much these days, but it used to introduce measurable hit, so the benefit needs to outweigh the cost). In any case, it has sufficiently been long time since we lost the other two librarres in our build, so changing it back to use three separate libraries would be yet another breaking move that I do not want to see---unfortunately it is way too late for that. So brian's patch in this series may need to be rebased to a newer base to expect a single library, I think.