Build artefacts cannot be found after successful build

[bolajahmad]

Running the pop build.. command does not work as expected.

Expected result: Assuming I am in my project directory which has a root Cargo.toml file. When I do pop build.. command, the resulting build artefact(s) should be in the target directory of my project.

Observed result: Build is successful but target folder is not created in my project directory. Instead it is located somewhere else entirely, determined by CARGO_TARGET_DIR env.

To recreate,

• Install pop-cli
• Create a new contracts project and write a contract
• Set CARGO_TARGET_DIR to some other pat
• Build your contract using pop build contract ..

We should not be depending on the CARGO_TARGET_DIR for the build of the contract, maybe we can try CARGI_MANIFEST_DIR instead? This configuration should also only be project based, it should not be used by the cli everytime I compile some other project because this is also what is currently happening.

[al3mart]

I was able to reproduce, thanks for reporting @bolajahmad

[al3mart]

We seem to be pulling the correct manifest path in

pop-cli/crates/pop-contracts/src/build.rs

Line 9 in 7135ef5

let manifest_path = get_manifest_path(path)?;

On my tests the manifest was retrieving the one on the expected location ManifestPath { path: "Cargo.toml" }

It seems that when executing the build, cargo contracts just ignores the manifest_path given in favor of the system CARGO_TARGET_DIR configuration.

Including a local cargo configuration for the project when executing pop new ... could be a way of avoiding this
https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure

[bolajahmad]

It's not just cargo contracts though, the same thing happen when I do pop build parachain as well. When I do the same build but with only cargo build, it works as expected.

I think we just need a local configuration file that we can read to determine such values like (the target directory, the root manifest TOML file). This also affects issues like #34 and #176 because there could be a build but we can't find it in the anticipated locations.

[al3mart]

Yeah, I believe my comment above won't really be of any help either, as cargo will take value of CARGO_TARGET_DIR over whatever we might be able to provide in a config for that project

[AlexD10S]

We seem to be pulling the correct manifest path in

pop-cli/crates/pop-contracts/src/build.rs

Line 9 in 7135ef5

let manifest_path = get_manifest_path(path)?;

On my tests the manifest was retrieving the one on the expected location ManifestPath { path: "Cargo.toml" }
It seems that when executing the build, cargo contracts just ignores the manifest_path given in favor of the system CARGO_TARGET_DIR configuration.

Including a local cargo configuration for the project when executing pop new ... could be a way of avoiding this https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure

As Ale mentioned cargo-contracts seems to enforce the take the root_package to place the artifacts when building the contract. See here and here.
Not sure what is the best approach here, force the CARGO_TARGET_DIR to our contract? with something like:
env::set_var("CARGO_TARGET_DIR", path.clone().unwrap_or(PathBuf::from("./")).join("target"));

[AlexD10S]

Tried to set the CARGO_TARGET_DIR variable in this PR #234
But then will need to do the same for pop contracts up and pop contracts call, Is that the best approach?

[bolajahmad]

Tried to set the CARGO_TARGET_DIR variable in this PR #234 But then will need to do the same for pop contracts up and pop contracts call, Is that the best approach?

That sounds like a hack, and also I think the issue also affects the parachain commands too so this route means we have to do the same for the parachain related commands also
Might be nice to consider an alternative where we can set the target_dir once and use multiple times

[al3mart]

It does affect parachains as well 👍

[brunopgalvao]

Might be nice to consider an alternative where we can set the target_dir once and use multiple times

Can you elaborate on this?

That sounds like a hack, and also I think the issue also affects the parachain commands too so this route means we have to do the same for the parachain related commands also

I do not think it is a "hack". It is straightforward, for every command that relies upon CARGO_TARGET_DIR the env variable would need to be set.