Fail to find the binary if CARGO_TARGET_DIR is set

[chevdor]

To reproduce:

• export CARGO_TARGET_DIR=/tmp/test/
• cargo test

The CLI binary, usually found when CARGO_TARGET_DIR is not set, will not be found:

---- test::it_fails_without_source stdout ----
thread 'test::it_fails_without_source' panicked at 'called `Result::unwrap()` on an `Err` value: CargoError { cause: Some(NotFoundError { path: "/tmp/test/debug/subwasm" }) }', cli/src/main.rs:75:66

This is especially an issue when CARGO_TARGET_DIR is set to benefit from caching.

NOTE: I am working currently on https://gitlab.com/chevdor/subwasm if you want more context

[epage]

Thanks for reporting this!

A workaround would be to use escargot to get the binary.

I might not have time for a couple of days to dig into this if you weren't planning to. Is this blocking you or is that workaround insufficient until then?

And apparently, there are some broken links in the docs, so I created #118

[chevdor]

Is this blocking you or is that workaround insufficient until then?

This is not blocking me at all for now, no worries. I disabled my tests for now but I will be happy to enable them again :)

[epage]

I wonder if there is a platform or rustc specific aspect to this.

I just ran

assert_cmd $ TMPDIR=/Users/edpage/src/tmp/ CARGO_TARGET_DIR=/Users/edpage/src/tmp/ cargo test

(the TMPDIR is to workaround an IT thing)

assert_cmd on a Mac with 1.51.0 passes tests that lookup and run a binary included in assert_cmd (bin_fixture).

[epage]

Either way, I expect #120 to help

[chevdor]

Either way, I expect #120 to help

It may help in some cases but I tested again today and that does not seem to fix the issue.

[epage]

I think I missed the update on which crate. It looks like you are using assert_cmd for unit/whitebox tests (in src/), rather than integration/blackbox tests (in tests/). I do not believe the binary is guaranteed to be compiled at that. When not overriding the directory, I think it works just because something else had left behind an executable.

This is documented in the limitations

Going ahead and closing assuming this is the root cause. Feel free to ask for this to be re-opened if something still needs addressing.