"extension-module" feature causing problems for proc_macro crate

[m-ou-se]

See m-ou-se/inline-python#27

Enabling features = ["extension-module"] on pyo3 in a crate that uses inline-python gives a linker error, because "extension-module" is then also enabled within inline-python-macros, which contains the proc macro that will use pyo3 to compile the Python code to bytecode. That crate is not an extension module, so leaving the symbols undefined will not work, as it won't be loaded by Python, but by Rustc.

This makes me think that "extension-module" should not be a feature, as cargo features should be strictly additive. That the end user is making an extension module, doesn't always mean that everything in the dependency tree will end up in an extension module, although this might very well be limited to procedural macros.

However, I don't know of a solution. Even if the ffi part would be split off into a separate crate, it'd still need to be compiled with different linker flags for the procedural macro than for the final crate. Having a separate crate just for linking to the Python libraries might work, but will probably cause confusion and other problems.

Any ideas?

[m-ou-se]

This is mostly a duplicate of #771, with the added detail that it's not about a bin crate here, but about a (proc_macro) lib crate.

This might make a solution involving rustc-bin-link-arg trickier.