From: Eric Sunshine <ericsunshine@gmail.com>
Date: Fri, 19 Sep 2025 20:24:34 GMT
Subject: Re: [PATCH v2 07/18] build: introduce rust
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:
> 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.

> > > +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?