From: Eric Sunshine <sunshine@sunshineco.com>
Date: Wed, 17 Sep 2025 08:51:28 GMT
Subject: Re: [PATCH v2 13/18] build-helper: link against libgit.a and any other required C libraries
Message-ID: <CAPig+cTZch_pvfurtjBTNphMeRQL6jSBSjNY-4mffjoXZ4eqcw@mail.gmail.com>
In-Reply-To: <6a27e07e6310b6cad0e3feae817269b9b8eaed69.1758071798.git.gitgitgadget@gmail.com>

On Tue, Sep 16, 2025 at 9:18 PM Ezekiel Newren via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> build-helper: link against libgit.a and any other required C libraries
>
> Don't link against the C libraries when building with Make or Meson.
> Run cargo tests like this:
> cd rust && cargo clean && USE_LINKING=true cargo test
>
> Signed-off-by: Ezekiel Newren <ezekielnewren@gmail.com>
> ---

Perhaps it's because I haven't been following the discussion closely
enough, but the above commit message leaves me entirely in the dark.
After reading and rereading it several times, I suppose it is trying
to address some difference between building with `cargo` vs. building
with Make or Meson, but it gives no explanation of what the
differences are or what problem it is trying to solve. So, please
enhance the commit message to begin with the "why" and then proceed to
the "what" or "how".

> diff --git a/rust/build-helper/Cargo.toml b/rust/build-helper/Cargo.toml
> @@ -4,4 +4,3 @@ version = "0.1.0"
>  edition = "2021"
>
>  [dependencies]
> -

This seems merely to be deleting a blank line which probably shouldn't
have been present in the first place. Rather than fixing the "problem"
here, it would make more sense to eliminate the blank line in the
patch which introduced it in the first place.

> diff --git a/rust/build-helper/src/lib.rs b/rust/build-helper/src/lib.rs
> @@ -0,0 +1,84 @@
> +use std::collections::HashMap;
> +use std::path::PathBuf;
> +
> +

If I'm not mistaken, it is uncommon to have two blank lines like this
in Rust code.

> +fn parse_bool_from_str(value: &str) -> bool {
> +    match value {
> +        "1" | "true"  | "yes" | "on"  => true,
> +        "0" | "false" | "no"  | "off" => false,
> +        _ => false
> +    }
> +}

Or, more simply:

    fn parse_bool_from_str(value: &str) -> bool {
        match value {
            "1" | "true"  | "yes" | "on"  => true,
            _ => false
        }
    }

(Though, admittedly, I'd probably lean toward writing the function the
same way you did.)

> +/// To build without linking against C libraries run `USE_LINKING=false cargo build`
> +/// To run tests set GIT_BUILD_DIR and run `USE_LINKING=true cargo test`
> +pub struct BuildHelper {
> +    crate_env: HashMap<String, String>,
> +}
> +
> +

Nit: unnecessary extra blank line

> +impl BuildHelper {
> +    pub fn build(self) {
> +        let use_linking = parse_bool_from_option(self.crate_env.get("USE_LINKING"), self.crate_env.get("CARGO_TARGET_DIR").is_none());
> +        ...
> +            println!("cargo:warning={} is not linking against C objects, `USE_LINKING=true cargo test`", self.crate_env["CARGO_PKG_NAME"]);

There are more than a few developers on this project (including
myself) who still use 80-column editors and terminals. As a general
style guideline, this project does recommend wrapping code to fit
within 80 columns (except in cases when doing so would severely hurt
readability). I imagine that the same sort of guideline would be
appreciated in Rust code, as well, by those who still stick with 80
columns.

I bring this up because, although it hasn't been such a big deal with
the existing C code, assuming that developers run `rustfmt` on the
code before sending a patch series, then this may become an issue if
different developers have `rustfmt` configured to enforce different
maximum column width, especially since `rustfmt` is likely to reformat
the entire file rather than just the region that has just been edited.
So, if this code gets checked in as-is with these very wide lines, and
then someone else, who has `rustfmt` configured for 80-columns edits
the file, then it becomes a problem.

As such, can we also add a project-wide `rustfmt.toml` which, at
minimum, sets the maximum line width to 80? For instance:

    max_width = 80