Anchor deploy fails when CARGO_TARGET_DIR is set.

[uttarayan21]

On anchor cli version 0.18.0 installed using cargo install --git https://github.com/project-serum/anchor anchor-cli --locked

When anchor build is used output is generated in $CARGO_TARGET_DIR/target/deploy/basic_0.so but the anchor deploy looks for it in the current directory.

Using anchor build -- --bpf-out-dir ./target/deploy generates the library inside $PWD/programs/basic-0/target/deploy

unset -int the CARGO_TARGET_DIR makes anchor work as expected.

Also anchor build -- --bpf-out-dir "$PWD/target/deploy" works fine.

[Henry-E]

curious if this ever got fixed, tempted to close

[dimalinux]

The problem is that the code base is hard-coding the target directory everywhere instead of asking cargo where the target directory is located. Here is an example:
https://github.com/coral-xyz/anchor/blob/v0.31.0/cli/src/rust_template.rs#L229

This issue is deeper than just ignoring CARGO_TARGET_DIR and .cargo/config.toml. It means the Anchor.toml file can only be placed at the very top of a workspace. Otherwise anchor build will put artifacts in the target directory at the top of the workspace, because it is invoking cargo build-sbf, but anchor won't be able to find those artifacts later.

Given that the anchor CLI already invokes cargo, one solution would be to ask cargo where the target directory is located. Here's a command-line example (obviously, when invoking it in Rust you don't need jq).

cargo metadata --format-version=1 | jq -r '.target_directory'

If people like the idea of using cargo metadata, I could even create a pull request. Or a core developer could replace all the instances of Path::new("target") with a cli crate function that asks cargo for the target directory fairly easily.

[dimalinux]

@jacobcreech The issue was closed, but you never answered the question as to whether you would accept a pull request that fixes the issue. It wouldn't be that many lines of code to change, and I'd be glad to submit the pull.

[jacobcreech]

@dimalinux happy to accept a pull request. I misread your original statement as it was fine now.

[dimalinux]

@jacobcreech wrote:

@dimalinux happy to accept a pull request. I misread your original statement as it was fine now.

The PR is ready: #3817

Happy to make any changes to it if reviewers want anything.