Does it make sense to publish libproc_macro?

[eqrion]

Currently cbindgen depends on syn for parsing rust which depends on proc-macro2 which depends on proc-macro.

This works, but it means that the binary depends on rustc libs being in LD_LIBRARY_PATH, which leads to linking errors when running the binary outside of cargo run. See rust-lang/rust#47931.

I noticed that rustfmt seems to get around this by using a published version of libsyntax. Does it make sense to have a published version of libproc_macro so we could do the same? I believe all of libproc_macros dependencies are currently published.

cc @staktrace

[alexcrichton]

Ah unfortunately not, I think the issue with bindgen is one we would want to fix in proc-macro2

[staktrace]

@alexcrichton How do you propose to do that?

[alexcrichton]

Binaries shouldn't ever depend on proc_macro, so if a binary depends on proc-macro2 then proc-macro2 shouldn't depend on proc_macro.

This'd probably involve adding a feature to proc-macro2 to say "don't link to proc_macro" and turn it on by deafult.

[staktrace]

Binaries shouldn't ever depend on proc_macro, so if a binary depends on proc-macro2 then proc-macro2 shouldn't depend on proc_macro.

Sounds like this applies to the quote and syn crates as well since those also depend on proc_macro.

This'd probably involve adding a feature to proc-macro2 to say "don't link to proc_macro" and turn it on by deafult.

Is this something you can specify in the Cargo.toml? It's not clear to me how you'd do this.

[staktrace]

@alexcrichton FYI since we didn't have any better options I went ahead and forked proc_macro into a standalone crate: https://crates.io/crates/rustc-ap-proc_macro. I also forked proc-macro2, quote, and syn, into standalone-proc-macro2 etc. and now we finally have a working cbindgen again. It only builds with nightly rustc so it's less than ideal but better than nothing. Still hoping we can resolve this with rust-lang/rust#48217 so that I can unfork all these things.

[alexcrichton]

dtolnay/proc-macro2#65 is the strategy I envisioned. That wouldn't require forking anything and would largely just require bindgen to tweak how it depends on syn.