Respect build.target when getting target dir

[ark0f]

• Use cargo_metadata crate
• Respect build.target when getting target dir
• Introduce RustTarget to cope better with future changes
• Add CARGO_MAKE_CRATE_CUSTOM_TRIPLE_TARGET_DIRECTORY env var

Fixes #557

[codecov-commenter]

Codecov Report

Merging #554 (537ec71) into 0.33.0 (30b6ba4) will increase coverage by 0.04%.
The diff coverage is 87.80%.

@@            Coverage Diff             @@
##           0.33.0     #554      +/-   ##
==========================================
+ Coverage   93.01%   93.05%   +0.04%     
==========================================
  Files          98       98              
  Lines       19283    19278       -5     
==========================================
+ Hits        17936    17940       +4     
+ Misses       1347     1338       -9     

Impacted Files	Coverage Δ
src/lib/types.rs	86.21% <ø> (+0.30%)	⬆️
src/lib/environment/crateinfo_test.rs	99.54% <85.71%> (-0.46%)	⬇️
src/lib/environment/crateinfo.rs	89.22% <86.95%> (+4.39%)	⬆️
src/lib/environment/mod.rs	92.98% <100.00%> (-0.18%)	⬇️
src/lib/cli.rs	91.81% <0.00%> (-0.44%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 30b6ba4...537ec71. Read the comment docs.

[ark0f]

cargo FS structure looks like this:

target
\---debug
\---x86_64-custom-target
    \---debug

so it can be wrong behavior. Is it better to introduce a new env var?

[sagiegurari]

why do we need it in the deserialize? why not keep it simple and do it in the usage as today?

[ark0f]

'Cause it will lead us to code repetition. We need to trim string in crate_target_dir and crate_target_triple, but original string can be useful for env var like CARGO_MAKE_IS_CUSTOM_TARGET_TRIPLE

[sagiegurari]

Thanks a lot for the continued effort on this one :)

Is it better to introduce a new env var?

can you explain a bit? what new var did you have in mind? how would they be used if there were 2, meaning how do users know which one to use?

[ark0f]

can you explain a bit?

Behavior with custom target triple:

• cargo creates target folder with build scripts in it
• cargo creates target/my_custom_triple folder with the rest

I don't know can cargo store there something else and will behavior be changed in the future.

What about workspaces? cargo ignores .cargo/config of member if you call cargo in workspace root (a bug?), but don't if you do it in member's folder, so you see that member will store its artifacts in target/my_custom_triple when others do it in target

what new var did you have in mind?

Something like CARGO_MAKE_CRATE_CUSTOM_TRIPLE_TARGET_DIRECTORY

how would they be used if there were 2, meaning how do users know which one to use?

User will decide which directory he needs - folder of custom target triple (target/my_custom_triple) or folder of host (target)

[sagiegurari]

@ark0f thanks a lot for the answers and PR. i agree with your approach of adding another env var.
tell me when its ready :)

[sagiegurari]

looks awesome @ark0f thanks a lot

@pheki can you please verify that your use case is fixed with this PR?

After that i'll merge this into the 0.33 branch

[pheki]

Oh, I missed this PR... It's great and I've verified, it fixes my use case.

Curiously, I'm also using a custom target, but its being set on [env] then passed in cargo build --target=${RUST_TARGET}, so I won't be able to use this new env var, but the current approach of joining the path works fine.

[sagiegurari]

@pheki thanks for confirming :)

@ark0f merging this. thanks a lot!!!