I have tested this with the 'iced' crate and its examples.
Ran 'cargo build --all', also 'cargo build --all-targets' just to be sure.
After a long build, executables appeared in the 'target/debug/' directory.
Yet when I run, for example, 'cargo build --package exit', it rebuilds the package and then rewrites that 'exit' executable in the 'target/debug/' directory.
Same happens when I run a 'cargo build --all' after that - it rewrites it again.
(And I checked, sha256sum of a file from 'cargo build --all' and a file from 'cargo build --package exit' are different)
I have pre-compiled all packages specifically to 'cargo run' them instantly, yet I don't get why it doesn't work as I expect it to.
If anyone is able to provide some explanation or a link to a documentation page explaining that, I would be very grateful.
This is because, when you build a given set of packages, only the features of those packages’ dependencies required by those packages are enabled. So, cargo build --package exit will have fewer features enabled than cargo build --all, and thus produce a different result.
If this is undesirable, you can use cargo build --all --bin exit instead. Selecting a target rather than a package does not have this filtering effect — the other packages will still be in the build graph.
Also, some other information not answering your question:
--all is deprecated and you should be using --workspace instead; they mean the same thing.
If you want to build everything, you need cargo build --workspace --all-targets in one command, not two separate commands. --all-targets builds all targets of the selected packages.
I see, thank you very much for your answer. It got me on the right track.
In my case, I wanted to build all example --bins and then run them when needed, yet cargo run doesn't have a --workspace flag and can only build in the scope of one package.
But I've found a solution, using a currently unstable feature of cargo:
CARGO_RESOLVER_FEATURE_UNIFICATION=workspace cargo -Z feature-unification run -p exit