Invalid path to binary on Windows

[wiktorwieclaw]

PS C:\cansat\crates\cansat-stm32f4> cargo dfu     
    Finished dev [unoptimized + debuginfo] target(s) in 2.12s
    Searching for a connected device with known vid/pid pair.
    Found  STMicroelectronics STM32  BOOTLOADER
    Flashing "\\\\?\\C:\\cansat\\crates\\cansat-stm32f4\\target\\thumbv7em-none-eabihf\\debug\\cansat-stm32f4"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: File(Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." })', C:\Users\Vixu\.cargo\registry\src\github.com-1ecc6299db9ec823\cargo-dfu-0.1.2\src\main.rs:143:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I think it may be because we are using a workspace. Here is the project.

Notice that it tries to find the target dir in cansat/crates/cansat-stm32f4/, but it should be just cansat/. As you can see, I'm calling cargo dfu from crates/cansat-stm32f4.

It works fine on my linux machine and the path gets properly resolved to:

/home/wiktor/Cosmo/cansat/target/thumbv7em-none-eabihf/debug/cansat-stm32f4

[wiktorwieclaw]

I've looked into the source code and the problem lies within the cargo-project crate.

cargo-project gets the target directory from 3 different sources, in this specific order:

1. CARGO_TARGET_DIR environment variable
2. build.target-dir property from .cargo/config.toml
3. Finds the workspace manifest (if it exists) and uses it's path to determine the target directory (this is probably where the bug occurs)

One can take advantage of the 1st or 2nd step to workaround the problem.

[wiktorwieclaw]

I found the bug! I submitted a PR for cargo-project.

I also made a fork of cargo-dfu that patches the dependency. It can be installed with:

cargo install --git https://github.com/wiktorwieclaw/cargo-dfu

[cecton]

Good catch! Can you make a PR of this here?

[cecton]

Oh you already did by cargo-project, nevermind! haha