Hello! I ran into an issue with cbindgen where I want to expose multiple C interfaces in a single static/dynamic library but want to avoid including one of these interfaces in the generated header file.

The reason for this is that our Wasm runtime has a C API but we also want to support the standard Wasm C API which has its own header files with extra information in them. It'd be somewhat confusing if the generated header file duplicated these definitions as it's missing important logic that's implemented in the standard header file.

I tried conditionally including the module with the standard definitions with a cargo feature and using the parse.expand options but ran into issues, one of which was that it required nightly Rust. So I tried splitting out the standard definitions into another crate and reexporting them but due to rust-lang/rfcs#2771 this didn't actually work out (I got the linking to work correctly on OSX and Windows but not on Linux).

Due to the size of this API and the fact that we're using macros to generate many functions, it'd be really nice to not have to manually blacklist each definition. Ideally there would be a way to tag a module path as excluded from parsing by cbindgen. Alternatively, a way to pass features for parsing without needing to cargo expand it might solve this problem too.

I'm open to alternatives and at some indeterminate point in the future some of my previous attempts may work, but it seems that this capability could still be useful.

Please let me know if this is a feature that you're interested in!