Re: [PATCH v2 07/18] build: introduce rust

From: Eric Sunshine <ericsunshine@gmail.com>
Date: Sep 19, 2025, 20:24 UTC
Message-ID: <CAPig+cSBEX5QGnzpBnVs_hKM2iUqcmA4-DzKDgkwpG9ZzWZ__w@mail.gmail.com>
In-Reply-To: <CAH=ZcbBBkk2B3PxKf54MRnAmURMK8W7ofFZBRS=ZzkuDNWsY9w@mail.gmail.com>

On Fri, Sep 19, 2025 at 4:11 PM Ezekiel Newren <ezekielnewren@gmail.com> wrote:

Show 10 quoted lines

> On Wed, Sep 17, 2025 at 2:26 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > Is ".idea" directory detritus from your chosen editor? If so, it
> > probably ought not be added to this list since we don't otherwise
> > ignore detritus from foreign tools such as that.
>
> Yes. I use the Jetbrains IDE's CLion and RustRover for C and Rust
> respectively. Jetbrains has an IDE for MANY languages and all of them
> use .idea/ as the folder for IDE specific configuration. I'm fine with
> keeping it out of .gitignore, but I wanted to know what the community
> thought. [...]

There is a bit of discussion about this later in this same email thread. If the project does ultimately decide to accept these .gitignore entries, adding them would be done via a patch or series of patches specifically aimed at that goal. Hence, I'd recommend omitting the ".idea" entry from this particular patch series.

Show 14 quoted lines

> > > +if rustup show active-toolchain | grep windows-msvc; then
> > > +  libfile="${crate}.lib"
> > > +  PATH="$(echo $PATH | tr ':' '\n' | grep -Ev "^(/mingw64/bin|/usr/bin)$" | paste -sd: -):/mingw64/bin:/usr/bin"
> > > +fi
> >
> > Please add either an in-code comment or a sentence/paragraph to the
> > commit message explaining why this PATH munging is needed.
>
> I will amend the commit with something like:
> On windows when building with msvc using shell scripts it looks for
> link in /mingw64/bin|/usr/bin when it actually needs to look somewhere
> else for the msvc linker program. Since removing these from PATH would
> break everything else in the shell; move them to be at the end of
> PATH.

I had to read and reread this several times but I think I get what it is saying. To paraphrase your explanation...

When building with `cargo` (I presume), and it comes time to link the program, the build process is looking for the Microsoft linker named LINK.exe but, due to PATH order, is instead finding the Unix command `link` (which is a specialized invocation of the more common `ln` command). As such, the build process incorrectly invokes the Unix `link` rather than the Microsoft LINK.exe and fails. To work around this problem, you move the standard Unix command-containing paths to the end of PATH so that the Microsoft LINK.exe is found first.

...does that sound correct?