Support generate header in different folders

[piaojin]

Now the whole rust code will be generated into one header file. So the header file may become large and large. It may be nice if generate header in different folders.

eg: Demo/a.rs -> Demo/a.rs header.h

[jrmuizel]

Indeed, having support for generating multiple header files would be valuable. Currently webrender_ffi_generated.h is at the top of the list of files that change often and are included in lots of places. If we could break it into pieces that would help with build churn.

A natural place to break into separate pieces is the crate boundary, however, since most of WebRender uses is in webrender_api, it may not make enough of a difference. The next obvious place is at the module boundary. Maybe that would work better.

[eqrion]

IIRC, the difficulty here is circular dependencies among header files.

Maybe when we break modules into multiple header files, we could move all forward declarations needed to a central header? Hmm, but maybe that central header could become a new bottleneck.

[jrmuizel]

Can modules have circular dependencies?

[emilio]

Yes.

pub mod foo {
    pub type T = i32;
    
    pub struct S {
        t: T,
        u: super::bar::U,
    }
}

pub mod bar {
    pub type U = super::foo::T;
}

fn main() {}

Compiles, for example.

[jrmuizel]

It looks like cycles are already a problem. I don't think we have a way of emitting a C header for the example that Emilio provided.

Perhaps we can just require there to be no cycles.

[ericdrobinson]

Has there been any movement on this?

I'd love to be able to split cbindgen's output into something like the following:

• CoreTypes.h - Contains a specific set of types that library consumers are likely to need to interface with.
• CoreAPI.h - Contains the set of APIs (and other relevant types) that a library wrapper implementation will need to interface with.
  • This header #includes CoreTypes.h.

This would allow me to build a library wrapper implementation in, say, C++ wherein I can #include a minimal set of relevant context into the wrapper's header files while leaving the wrapper's implementation files to #include the API. This would help end users of the wrapper implementation to not get inundated with access to all the APIs defined throughout the entire library (with the wrapper implementation, these are simply unnecessary internal implementation details).

Outside of C++20 modules (which don't have broad support yet), the standard approach to handling this in C++ is to use the PImpl pattern, which incurs the cost of an additional pointer indirection for every API call. It also does very little for the situation wherein an end consumer needs to interface with a type provided by the Rust library as importing a single header file for that type will also bring the entire API along with it.

Is there some way to achieve something like this with cbindgen today?