Why are proc macro crates required to be dependencies?

I wrote a procedural macro to generate code for a project, and when I tried to crompile it to the wasm32-unknown-unknown target, it failed to build. The likely cause is the same as this issue re: the musl target. Short explanation being that the proc_macro crate is dynamically linked, which the target doesn’t support, nor should it because to quote alex chrichton “there’s no reason to have a full Rust parser linked into a binary (when it’s not used)”.

To me that raises the question, why is a crate that exports a proc macro required to be a runtime dependency? The procedural macro itself needs the proc_macro crate as a dependency. But that procedural macro is merely a build dependency of whatever project uses it to generate code.

At first glance it appeared obvious that the dev-dependencies or build-dependencies sections of Cargo.toml were the appropriate place for a procedural macro crate, but the specification is pretty explicit that it’s only for tests/examples/benchmarks/build.rs. Can someone knowledgable explain why there’s apparently no way to add a procedural macro as a compilation-only dependency? If there’s actually no way to do this, is it a good starting point for a new feature to add it?

A proc-macro crate isn’t a runtime dependency. It’s compiled for the host architecture and loaded by the compiler while building your crate.

1 Like