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.

Sign up for GitHub

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

Jump to bottom

Maintain a more stable ordering of types #12

Closed
jrmuizel opened this issue May 15, 2017 · 5 comments
Closed

Maintain a more stable ordering of types #12

jrmuizel opened this issue May 15, 2017 · 5 comments

Comments

@jrmuizel
Copy link
Contributor

Anecdotally, it seems like if you change when I a type gets used it can end up changing order in the generated header which causes needless code churn. It might be nice to avoid this somehow.
@staktrace
Copy link
Contributor

staktrace commented Jul 31, 2017 •
edited
Loading

This is actually quite annoying for when my WR update cron job pushes patches, resulting in frequent merge conflicts. Is there something we can do to make the ordering stable? The SideOffsets2D_f32 keeps flip-flopping win the u32 variant.

@eqrion
Copy link
Collaborator

eqrion commented Aug 1, 2017

There are definitely improvements we can make for the ordering. Unfortunately I haven't had time to improve cbindgen recently.

The issue with SideOffsets2D_f32 and SideOffsets2D_u32 seems like it could be from some uses of HashMap, which is non deterministic across changes.

I pushed a new release that uses BTreeMap instead, which might help your case. Let me know if it's still bad.

@staktrace
Copy link
Contributor

Initial results look good. Thanks! I'm ok with closing this issue for now and reopening it later if it's still a problem.

@eqrion
Copy link
Collaborator

eqrion commented Aug 1, 2017

Okay cool. Let's keep this issue open for now, there are some other changes I'd like to make in the future.

@eqrion eqrion mentioned this issue Aug 16, 2017
Closed
@eqrion
Copy link
Collaborator

eqrion commented Aug 18, 2018

I'm going to close this now as I think we do okay here. If there's something specific that comes up, lets open a new issue.

@eqrion eqrion closed this as completed Aug 18, 2018
aanon4 pushed a commit to pimox/proxmox-backup-qemu that referenced this issue May 11, 2021
@Blub
add api check
b6e1737 
commit the current generated proxmox-backup-qemu.h as
'current-api.h' and run `diff -up` between the two in build
steps, so any changes to the C api are caught at build time.

cbindgen seems to be using a BTreeMap for the data, so it
should always come out sorted, so this should be a
stable-enough check.

Link: mozilla/cbindgen#12
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jrmuizel @staktrace @eqrion