So like [export.include]?

Using features should work, as long as you define it in the features section. It should generate #ifdefd functions nontheless. It may be an option to treat a feature as always-true or always-false and just skip its code generation...

According to the documentation [export.include] only adds things (and doesn't work like a whitelist):

# A list of additional items to always include in the generated bindings if they're
# found but otherwise don't appear to be used by the public API.

Maybe this isn't true?

I can only find "features" under [parse.expand], but we aren't expanding any crates.

Imagine that I have something like this in my crate:

#[cfg(feature = "platform-a")]
pub mod a;

#[cfg(feature = "platform-b")]
pub mod b;

#[cfg(feature = "platform-c")]
pub mod c;

If I then build with --features platform-a,platform-b I only want functions from mod a and mod b in the c headers.

Err, I meant the [defines] section.

So when you do something like:

[defines]
"feature=platform-a" = "PLATFORM_A"
"feature=platform-b" = "PLATFORM_B"
"feature=platform-c" = "PLATFORM_C"

You'll get something like:

#if defined(PLATFORM_A)
// stuff in `mod a`
#endif

And so on.

cool, that might be exactly what we need. I'll try it out

I tested it, and it doesn't work exactly as I hoped. Is it possible tto generate #if PLATFFORM_A == 1 instead?

Relying on defined() has bitten us in the past, you don't get any errors if you have typos and so on. So all our defines are always set, but to 0/1 depending on the value.

Now I noticed that you cannot have includes that depend on features. (i'll open new issues for things I run into)

I tested it, and it doesn't work exactly as I hoped. Is it possible tto generate #if PLATFFORM_A == 1 instead?

It is not impossible.

Relying on defined() has bitten us in the past, you don't get any errors if you have typos and so on. So all our defines are always set, but to 0/1 depending on the value.

As a workaround you could have something like the following in the header:

#if PLATFORM_A
#define CBINDGEN_PLATFORM_A
#endif

And so on, but that seems slightly annoying indeed.

Now I noticed that you cannot have includes that depend on features. (i'll open new issues for things I run into)

Well, you can have them in header section, or just inside one common #include and such. Not so convenient, but not sure it's a feature that I had heard about before. Not sure it's common enough to add a dedicated way to generate it from the config.

Thanks, with those two workarounds it works OK for us for now. This ended up being our final cbindgen config.

• Would you want better support for these usecases?
• Features work good-enough as whitelisting for us for now. But we would still prefer to manually write every single function we want to export in the same way that we can do with bindgen

Thanks for cbindgen and thanks for the quick responses!

Actually the problem that I have is that my bindgen symbols are being re-exported by cbindgen. I use the bindgen as use my_bindgen_lib and not pub mod or pub use. I don't understand how cbindgen finds them and re-exports them. This feature, excluding or including with a regex or glob would be super useful

@dzervas it may be you want /// cbindgen:ignore on the module that has all the bindings that you don't want exported?

I'm not sure if this should be a separate issue, but it sounded fairly close to this one. I've wished for a way to only export functions, types, and constants from a specific module. (In my case, I put all the relevant things to export in crate::ffi). The rest of the crate has a large public Rust API, so it's not really feasible to add /// cbindgen:ignore to everything else.

It's also a little different than include, but rather something like only or filter.

[export]
only = ["ffi::*"]

Currently functions are generated without include_item. Then does adding a bool flag to disabling this feature and using include_item work like a whitelist option?