Re: [PATCH 10/14] rust: add a build.rs script for tests

[Junio C Hamano <gitster@pobox.com>]

Ezekiel Newren <ezekielnewren@gmail.com> 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.