"extension-module" feature causing problems for proc_macro crate

See https://github.com/fusion-engineering/inline-python/issues/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?

Start with the linked inline-python issue and trace how the pyo3 "extension-module" feature reaches inline-python-macros, especially its proc macro use of pyo3. Reproduce the linker error in a crate using inline-python with that feature enabled; done requires a clear resolution for compiling the proc macro without inappropriate extension-module linker behavior.