Considering a restructure about x11-rs HOT 6 CLOSED

@robertknight

from x11-rs.

So to recap:

• One module per shared library, with corresponding functions => x11::{xlib,xi,xfixes,xinerama}...
• Constants and types in modules based on the header files they come from. Perhaps x11types::xlib::{...} . Or perhaps there should just be one module with all the relevant structs/constants, since the structs already have prefixes that namespace them - eg. 'x11types::{XIDeviceInfo, Success, Display ...}'
• One crate for statically linked X11, one for dynamically linked and one for constants/types shared between the two?

from x11-rs.

I guess the structure would depend on whether the bindings are generated at compile time or ahead of time. But glob re-exports into the root module would make the layout less important. If things are generated at compile time, I wouldn't see any benefit to splitting them up by header or library.

My first thought was to have types, constants and static functions all in the x11 module and dylib functions in the x11-dl module. But if libraries are feature gated in x11-dl to vastly improve compile time, then it may be worth it to merge them all into the same crate. This would require a macro similar to x11_link for each individual library, which isn't such a bad thing.

from x11-rs.

For generating constant definitions, someone else had a much better idea - generate C++ code which leverages the compiler's type inference to determine the type of macros: http://vojtech.kral.hk/en/rust-importing-c-constants-proof-of-concept/

from x11-rs.

One of the problems I was thinking of when generating bindings from the C headers is determining the types of the thousands of macros. I've been thinking recently that they can all be c_int unless they have an L suffix, in which case they can be c_long. It may be a little less ergonomic in many cases where the constant is meant for a type other than int, but it still seems like a cleaner solution than writing constants by hand like we have been doing.

from x11-rs.

Closing in favor of #40.

from x11-rs.