Is it possible to have a dependency in Cargo.toml, but only to force dependency to produce a loadable library, without making Rust compiler to link to that dependency?
So, I have a cdylib dependency, say, plugins and then a main binary, say, main. I want cargo to make sure plugins loadable library is always up-to-date when I run main binary. Basically, I want cargo run --package main to also implicitly do cargo build --package plugins).
However, I don't want Rust to do any linking to that "plugins" (which, I think, happens if I add it to the [dependencies] section).
It seems like having dependency crate-type is cdylib might do what I want, but it produces a warning:
The package plugin provides no linkable target. The compiler might raise an error while compiling main. Consider adding 'dylib' or 'rlib' to key crate-type in plugin's Cargo.toml. This warning might turn into a hard error in the future.
which I want to avoid. dylib type would make Rust to link to that dependency, which I don't want.
Cargo doesn't have a concept of non-linked dependency, so it can't be done directly AFAIK.
The two crates could be part of a single workspace, and then cargo build --all would build both. Maybe default-run would help to make cargo run work from the workspace, or maybe you could make an alias in .cargo/config.
They are part of the same workspace, but building everything would be a bit too extreme (as we have many-many other binaries which we don't really want to build every time).
What do you mean by an alias in .cargo/config?
P.S. I guess we can use detect "stale" loadable libraries during start of our binary and maybe spawn cargo build for them. Gnarly, but could work. It's all about developer UX, I want cargo run --package main to continue working and switch to loading some of the modules as plugins...
True, but things change all the time. One small change in dependencies / Cargo.lock, and here we go again, rebuilding the world. Which in our case is pretty big.