[PATCH] Makefile: pin cargo --target-dir to ./target

[PATCH] Makefile: pin cargo --target-dir to ./target

[Andy Koppe]

The Makefile assumes that cargo places build artifacts under ./target.
That assumption breaks if the user has a custom target dir setting, e.g.
in their ~/.cargo/config.toml file or in the CARGO_TARGET_DIR env var.
This results in a link error due to failing to find the gitcore library
built with cargo.

To fix this, pass '--target-dir target' to the cargo commands that build
gitcore. Add it directly to the recipes rather than to CARGO_ARGS, so
that it isn't lost if CARGO_ARGS is overridden.

Leave the contrib/libgit-{sys,rs} targets alone, as nothing depends on
the location of their build output.

The Meson build of gitcore already passes --target-dir explicitly.

Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index c649c93c51..aea99a3639 100644
--- a/Makefile
+++ b/Makefile
@@ -3039,7 +3039,7 @@ $(LIB_FILE): $(LIB_OBJS)
 ifndef NO_RUST
 ifeq ($(RUST_TARGETS),)
 $(RUST_LIB): Cargo.toml $(RUST_SOURCES) $(LIB_FILE)
-	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
+	$(QUIET_CARGO)cargo build $(CARGO_ARGS) --target-dir target
 else
 ifneq ($(words $(RUST_TARGETS)),1)
 ifneq ($(uname_S),Darwin)
@@ -3049,7 +3049,7 @@ endif
 
 RUST_MEMBER_LIBS = $(foreach target,$(RUST_TARGETS),target/$(target)/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME))
 $(RUST_MEMBER_LIBS): target/%/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME): Cargo.toml $(RUST_SOURCES) $(LIB_FILE)
-	$(QUIET_CARGO)cargo build $(CARGO_ARGS) --target $*
+	$(QUIET_CARGO)cargo build $(CARGO_ARGS) --target-dir target --target $*
 
 $(RUST_LIB): $(RUST_MEMBER_LIBS)
 	$(call mkdir_p_parent_template)
-- 
2.56.0

Re: [PATCH] Makefile: pin cargo --target-dir to ./target

[Patrick Steinhardt]

On Sun, Oct 18, 2026 at 09:53:05PM +0100, Andy Koppe wrote:
> The Makefile assumes that cargo places build artifacts under ./target.
> That assumption breaks if the user has a custom target dir setting, e.g.
> in their ~/.cargo/config.toml file or in the CARGO_TARGET_DIR env var.
> This results in a link error due to failing to find the gitcore library
> built with cargo.
> 
> To fix this, pass '--target-dir target' to the cargo commands that build
> gitcore. Add it directly to the recipes rather than to CARGO_ARGS, so
> that it isn't lost if CARGO_ARGS is overridden.
> 
> Leave the contrib/libgit-{sys,rs} targets alone, as nothing depends on
> the location of their build output.

Right. I sometimes wonder whether we maybe want to start merging this
into the main Rust library. But that's certainly a topic for another
day.

> The Meson build of gitcore already passes --target-dir explicitly.

Indeed it does.

> diff --git a/Makefile b/Makefile
> index c649c93c51..aea99a3639 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -3039,7 +3039,7 @@ $(LIB_FILE): $(LIB_OBJS)
>  ifndef NO_RUST
>  ifeq ($(RUST_TARGETS),)
>  $(RUST_LIB): Cargo.toml $(RUST_SOURCES) $(LIB_FILE)
> -	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
> +	$(QUIET_CARGO)cargo build $(CARGO_ARGS) --target-dir target
>  else
>  ifneq ($(words $(RUST_TARGETS)),1)
>  ifneq ($(uname_S),Darwin)
> @@ -3049,7 +3049,7 @@ endif
>  
>  RUST_MEMBER_LIBS = $(foreach target,$(RUST_TARGETS),target/$(target)/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME))
>  $(RUST_MEMBER_LIBS): target/%/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME): Cargo.toml $(RUST_SOURCES) $(LIB_FILE)
> -	$(QUIET_CARGO)cargo build $(CARGO_ARGS) --target $*
> +	$(QUIET_CARGO)cargo build $(CARGO_ARGS) --target-dir target --target $*
>  
>  $(RUST_LIB): $(RUST_MEMBER_LIBS)
>  	$(call mkdir_p_parent_template)

Makes sense. I would have preferred to use the "--target-dir=target"
form, but that really only is a nit that does not warrant a reroll in my
opinion.

So overall this patch looks good to me, thanks!

Patrick

Re: [PATCH] Makefile: pin cargo --target-dir to ./target

[Junio C Hamano]

Andy Koppe <andy.koppe@gmail.com> writes:

> The Makefile assumes that cargo places build artifacts under ./target.
> That assumption breaks if the user has a custom target dir setting, e.g.
> in their ~/.cargo/config.toml file or in the CARGO_TARGET_DIR env var.
> This results in a link error due to failing to find the gitcore library
> built with cargo.
>
> To fix this, pass '--target-dir target' to the cargo commands that build
> gitcore. Add it directly to the recipes rather than to CARGO_ARGS, so
> that it isn't lost if CARGO_ARGS is overridden.
>
> Leave the contrib/libgit-{sys,rs} targets alone, as nothing depends on
> the location of their build output.
>
> The Meson build of gitcore already passes --target-dir explicitly.
>
> Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
> ---
>  Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

The change might make sense, but these areas are touched by other
topics in flight.

Given that they both appear on the same line as $(CARGO_ARGS)
appears, I have to wonder if we want to instead just add a single

    CARGO_ARGS += --target-dir target

somewhere early that are unreleated to these individual rules?

> diff --git a/Makefile b/Makefile
> index c649c93c51..aea99a3639 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -3039,7 +3039,7 @@ $(LIB_FILE): $(LIB_OBJS)
>  ifndef NO_RUST
>  ifeq ($(RUST_TARGETS),)
>  $(RUST_LIB): Cargo.toml $(RUST_SOURCES) $(LIB_FILE)
> -	$(QUIET_CARGO)cargo build $(CARGO_ARGS)
> +	$(QUIET_CARGO)cargo build $(CARGO_ARGS) --target-dir target
>  else
>  ifneq ($(words $(RUST_TARGETS)),1)
>  ifneq ($(uname_S),Darwin)
> @@ -3049,7 +3049,7 @@ endif
>  
>  RUST_MEMBER_LIBS = $(foreach target,$(RUST_TARGETS),target/$(target)/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME))
>  $(RUST_MEMBER_LIBS): target/%/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME): Cargo.toml $(RUST_SOURCES) $(LIB_FILE)
> -	$(QUIET_CARGO)cargo build $(CARGO_ARGS) --target $*
> +	$(QUIET_CARGO)cargo build $(CARGO_ARGS) --target-dir target --target $*
>  
>  $(RUST_LIB): $(RUST_MEMBER_LIBS)
>  	$(call mkdir_p_parent_template)

Re: [PATCH] Makefile: pin cargo --target-dir to ./target

[Andy Koppe]

On Mon, 19 Oct 2026 at 17:07, Junio C Hamano <gitster@pobox.com> wrote:
> Andy Koppe <andy.koppe@gmail.com> writes:
> > The Makefile assumes that cargo places build artifacts under ./target.
> > That assumption breaks if the user has a custom target dir setting, e.g.
> > in their ~/.cargo/config.toml file or in the CARGO_TARGET_DIR env var.
> > This results in a link error due to failing to find the gitcore library
> > built with cargo.
> >
> > To fix this, pass '--target-dir target' to the cargo commands that build
> > gitcore. Add it directly to the recipes rather than to CARGO_ARGS, so
> > that it isn't lost if CARGO_ARGS is overridden.
>
> The change might make sense, but these areas are touched by other
> topics in flight.
>
> Given that they both appear on the same line as $(CARGO_ARGS)
> appears, I have to wonder if we want to instead just add a single
>
>     CARGO_ARGS += --target-dir target
>
> somewhere early that are unreleated to these individual rules?

The problem I see with that approach is that CARGO_ARGS looks like it
is intended for build preferences similar to CFLAGS or LDFLAGS that
could be overridden on the make command line, whereas the target dir
is a hard requirement of the subsequent link step.

I suppose `override CARGO_ARGS += --target-dir target` would avoid
that concern, but also set a trap because any subsequent modifications
of the variable without `override` would be quietly ignored.

The conflicting topic apparently is mh/rust-crate-subdir by Mike
Hommey, which moves things into a 'rust' subdirectory, but is looking
somewhat stalled:
https://lore.kernel.org/git/20260917060415.2986259-1-mh@glandium.org/

I'd of course be happy to reapply the --target-dir tweak here on top
of that if it does go ahead, or for Mike to just add it there.

Andy

Re: [PATCH] Makefile: pin cargo --target-dir to ./target

[Junio C Hamano]

Andy Koppe <andy.koppe@gmail.com> writes:

> The problem I see with that approach is that CARGO_ARGS looks like it
> is intended for build preferences similar to CFLAGS or LDFLAGS that
> could be overridden on the make command line, whereas the target dir
> is a hard requirement of the subsequent link step.
>
> I suppose `override CARGO_ARGS += --target-dir target` would avoid
> that concern, but also set a trap because any subsequent modifications
> of the variable without `override` would be quietly ignored.

But we are already tweaking it with += in the Makefile, aren't we?

    # Rust flags
    CARGO_ARGS =
    ifndef V
    CARGO_ARGS += --quiet
    endif
    ifndef DEBUG
    CARGO_ARGS += --release
    endif
    

Re: [PATCH] Makefile: pin cargo --target-dir to ./target

[Andy Koppe]

Junio C Hamano <gitster@pobox.com> wrote:
>
> Andy Koppe <andy.koppe@gmail.com> writes:
>
> > The problem I see with that approach is that CARGO_ARGS looks like it
> > is intended for build preferences similar to CFLAGS or LDFLAGS that
> > could be overridden on the make command line, whereas the target dir
> > is a hard requirement of the subsequent link step.
> >
> > I suppose `override CARGO_ARGS += --target-dir target` would avoid
> > that concern, but also set a trap because any subsequent modifications
> > of the variable without `override` would be quietly ignored.
>
> But we are already tweaking it with += in the Makefile, aren't we?
>
>     # Rust flags
>     CARGO_ARGS =
>     ifndef V
>     CARGO_ARGS += --quiet
>     endif
>     ifndef DEBUG
>     CARGO_ARGS += --release
>     endif

Yes, but those are preferences that can be overridden on the make
command line without doing harm (within reason), similar to the
default 'CFLAGS = -g -O2 -Wall', whereas the --target-dir should
always be passed to ensure the cargo output is going where it's
expected.

Re: [PATCH] Makefile: pin cargo --target-dir to ./target

[Junio C Hamano]

Andy Koppe <andy.koppe@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Andy Koppe <andy.koppe@gmail.com> writes:
>>
>> > The problem I see with that approach is that CARGO_ARGS looks like it
>> > is intended for build preferences similar to CFLAGS or LDFLAGS that
>> > could be overridden on the make command line, whereas the target dir
>> > is a hard requirement of the subsequent link step.
>> >
>> > I suppose `override CARGO_ARGS += --target-dir target` would avoid
>> > that concern, but also set a trap because any subsequent modifications
>> > of the variable without `override` would be quietly ignored.
>>
>> But we are already tweaking it with += in the Makefile, aren't we?
>>
>>     # Rust flags
>>     CARGO_ARGS =
>>     ifndef V
>>     CARGO_ARGS += --quiet
>>     endif
>>     ifndef DEBUG
>>     CARGO_ARGS += --release
>>     endif
>
> Yes, but those are preferences that can be overridden on the make
> command line without doing harm (within reason), similar to the
> default 'CFLAGS = -g -O2 -Wall', whereas the --target-dir should
> always be passed to ensure the cargo output is going where it's
> expected.

That's fair.

So if we wanted to go that route, we'd need a companion variable for
CARGO_ARGS that is similar to BASIC_CFLAGS we have for CFLAGS, which
may not be a bad thing to have in the longer term assuming that we
would have more targets that need to use CARGO_ARGS.

Anyway, this was not an objection to the way the patch was
originally written.  Just I noticed while resolving conflicts
between in-flight topics.

Thanks.