Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consolidate types and constants #84

Open
ghost opened this issue Jun 12, 2018 · 1 comment
Open

Consolidate types and constants #84

ghost opened this issue Jun 12, 2018 · 1 comment

Comments

@ghost
Copy link

ghost commented Jun 12, 2018

I have a few issues with the way these crates are structured.

(1) x11 and x11-dl both expose their own copies of all native types and constants. This is currently done using symlinks to the source files, but it would be much nicer to just include the types in one crate (x11) and have others (x11-dl) depend on this crate for its types and constants (but of course without the need to statically link any C libraries to use these types). If backwards compatibility is desired, these types and constants can be pub used into x11-dl, but I don't think this is the best thing to do. This and the next problem would likely entail a version bump to 3.0.0...

(2) Everything currently lies within public submodules within the main crate(s). For example, one of the most commonly used types is x11::xlib::Display/x11_dl::xlib::Display. In addition to moving types into one crate, I believe these should be exposed to the root of the crate (i.e. x11::Display). They're currently lumped into modules somewhat arbitrarily, based only on what X library they seem to be most relevant to. If we move everything into the crate root, it will (a) be easier to find and reference these types and (b) be easier to transition to bindings generated from the C headers if desired.

@ghost
Copy link
Author

ghost commented Aug 4, 2018

Now that #90 has occurred, I'll be putting more thought into this and #87. The existing types and constants can remain mostly unchanged. The x11_link! macro made sense at the time, but I'm thinking now that gl_generator has a nicer solution to generating bindings. There is no XML spec for the X11 library functions AFAIK, but they can still be loaded either from a serde format like JSON or, even better, an easily parsable, minimal subset of C function declarations. Examples.

// xlib.json
{
    functions: [
        { name: "XOpenDisplay", return_type: "*mut Display", params: ["*const c_char"] }
    ]
}

or

// xlib.cdecls
Display *XOpenDisplay (const char *);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0 participants