Cargo build vs cargo run discrepancy

[Abso1ut3Zer0]

Hi,

I'm updating a CLI app that I've build using the clap crate, but I'm encountering very strange build behavior. When I run the cargo build command to run my CLI, it does not seem to pickup the new subcommand I've made.

I have deleted the binary itself under /target/debug and tried deleting the entire /target directory. I've also cleared the build cache and run cargo clean, but nothing seems to work.

What is particularly strange is that if I run cargo run -- -h within application's root directory, it picks up the changes with my new subcommand.

Has anyone else experienced this problem?

[drewtato]

What are the exact commands you're using to build and run your app, and in what directory?

[Abso1ut3Zer0]

So I will do the following:

1. cargo clean
2. cargo build (within the root of the application directory)
3. cd to /target/debug
4. my_cli -h

Separately, I will run the following within the root of the application directory:
cargo run -- -h

The former does not pickup my new subcommand, but the second one does. For some additional context, my repo is a workspace, but it is not published to cargo so dependencies within the workspace are using local paths.

[drewtato]

Perhaps it's features?

Binaries are skipped if they have required-features that are missing.

That seems like the only thing that could do it, assuming everything else is happening as described.

cargo build - The Cargo Book

[Abso1ut3Zer0]

My Cargo.toml is pretty vanilla besides it being part of a workspace, so I am not using features for this CLI at the moment. I'm at a loss as to what would be causing this...

[quinedot]

What's your PATH? (echo "$PATH")

[mbrubeck]

What does which my_cli print? What if you run ./my_cli to ensure you are running the executable in the current directory, rather than one installed somewhere else in your $PATH?

[Abso1ut3Zer0]

Ah that is what it was! I'm being a dummy. I have another version of the executable in my $PATH.