Generate headers for re-exports

[dbrgn]

I have a crate that imports and re-exports extern "C" functions and repr(C) types from another crate.

pub use saltyrtc_client_ffi::{salty_event_loop_t, salty_remote_t, salty_keypair_t};
pub use saltyrtc_client_ffi::{salty_event_loop_new, salty_event_loop_free};
pub use saltyrtc_client_ffi::{salty_event_loop_get_remote, salty_event_loop_free_remote};
pub use saltyrtc_client_ffi::{salty_keypair_new, salty_keypair_free};

But the types did not end up in the header file. So I enabled parse_deps:

[parse]
parse_deps = true
include = ["saltyrtc-client-ffi"]

Unfortunately that did not help. I assumed it was because I'm not actually using those types. So I explicitly added them to the export section:

[export]
include = [
    "salty_event_loop_new", "salty_event_loop_free",
    "salty_event_loop_get_remote", "salty_event_loop_free_remote",
    "salty_keypair_new", "salty_keypair_free",
]

But the header file is still empty (except for the include guard and the std- includes).

How can I include re-exported types in my generated header files?

(For the record, I'm generating the header file with a build.rs file.)

[dbrgn]

Even if I have one of these types in the signature of my own exported functions, they aren't exported.

[dbrgn]

Sorry for the triple-post, but here's some more information.

When running cbindgen on the commandline (with cbindgen -l c -c cbindgen.toml -d .), I get these warnings:

WARN: Can't find salty_client_t. This usually means that this type was incompatible or not found.
WARN: Can't find salty_keypair_t. This usually means that this type was incompatible or not found.
WARN: Can't find salty_remote_t. This usually means that this type was incompatible or not found.

This is what these types look like:

#[no_mangle]
pub enum salty_client_t {}

When generating headers in that other crate directly, header definitions for these types are being generated properly.

[dbrgn]

Oh, it looks like this isn't the problem of cbindgen itself – the symbols are not actually visible from the cdylib: https://github.com/rust-lang/rust/issues/36342 😞 Potential hacky workaround is here: https://github.com/rust-lang/rust/issues/36342#issuecomment-362269890

[eqrion]

Oh, it looks like this isn't the problem of cbindgen itself – the symbols are not actually visible from the cdylib: rust-lang/rust#36342 😞 Potential hacky workaround is here: rust-lang/rust#36342 (comment)

Per this, I'm going to close this issue. Feel free to re-open if this is confirmed to be a cbindgen issue.

[gurchetansingh]

So I'm running into a very similar issue. I have very simple repr[(C)] structs from the Rust crate.

// Foo crate
[repr(C)]
pub struct FooData {
   pub flags: u32,
   pub id: u32,     
}

I try to re-export as suggested previously:

// lib.rs where FFI bindings live
extern crate Foo;

pub type FooData = Foo::FooData;

#[no_mangle]
pub extern "C" fn bar() -> *mut foo {
    Foo::new_data as *mut foo
}

Unfortunately, only the following shows up in the C header:

typedef FooData FooData;

I would like the following:

typedef struct FooData {
     uint32_t flags;
     uint32_t id;
} FooData;

How can I achieve this? Am I missing anything?

[poszu]

@gurchetansingh, I had the same problem. I managed to make it work by:

1. enable parsing dependencies either by build.rs or cbindgen.toml. In build.rs add:

cbindgen::Builder::new()
    .with_parse_deps(true)
    .with_parse_include(&["<name of the crate that contains the struct>"])
    // ... all other usual stuff

2. pub use the struct:

pub use Foo::FooData;