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

Provide more control over type names in generated headers #43

Open
trombonehero opened this issue Jun 7, 2016 · 1 comment
Open

Provide more control over type names in generated headers #43

trombonehero opened this issue Jun 7, 2016 · 1 comment

Comments

@trombonehero
Copy link

It would be handy if I could annotate types with the name I want the C header to use. This wouldn't work with functions (since the name in the header must correspond to the name in the library), but it would for types, since the thing we actually care about there is the ABI rather than the name.

As things stand today, I have to live with non-C-friendly type names (e.g., State, which is a recipe for trouble in C's flat namespace) or else I need to compromise on my Rust names (e.g., struct foolib_state). I'd like the ability to explicitly name my generated C types:

#[repr(C)]
#[cheddar(name=foolib_state)]
pub struct State {
    // ...
}

Alternatively (or also?), it would be great if I could tell rusty-cheddar how to automatically C-ify my names:

Cheddar::new()
    .expect(...)
    .prefix("foolib_")
    .convert_camel_cased_type_names(true)
    .run_build(...)
@Sean1708
Copy link
Owner

Sean1708 commented Jun 8, 2016

I really like this idea, I'll have to give it some thought though. I think the former suggestion is better in the long run, but I don't think there's any way to do it on stable yet (since you'd have to register the attribute with the actual compiler). So I'll probably implement the second suggestion for now, then come back to the first one later if I can think of a good way to implement it.

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

2 participants