Codecov Report

Attention: Patch coverage is 89.18919% with 4 lines in your changes missing coverage. Please review.

Project coverage is 93.24%. Comparing base (655a937) to head (6084033).
Report is 24 commits behind head on main.

@@            Coverage Diff             @@
##             main      #11      +/-   ##
==========================================
+ Coverage   93.05%   93.24%   +0.18%     
==========================================
  Files           1        1              
  Lines         144      222      +78     
==========================================
+ Hits          134      207      +73     
- Misses         10       15       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@djc so how do I now get updated Windows bindings when I need to add support for a new function? I don't have access to a Windows machine to run bindgen.

@djc so how do I now get updated Windows bindings when I need to add support for a new function? I don't have access to a Windows machine to run bindgen.

I did it via CI, which will print the newly generated bindings when the comparison fails -- but you have to get the integration test to run, which only happens when the library compiles. Might be an option to put the codegen in a separate crate to make that easier...

I did it via CI, which will print the newly generated bindings when the comparison fails -- but you have to get the integration test to run, which only happens when the library compiles. Might be an option to put the codegen in a separate crate to make that easier...

Hm. This is getting complex fast. I'm tempted to revert #14 and just go back to what we had before...

If you just make a separate branch/PR that adds the newly required symbols only in the codegen test, that should make things easier.

but you have to get the integration test to run

Could we run bindgen in build.rs? IIRC @martinthomson suggested something similar.

but you have to get the integration test to run

Could we run bindgen in build.rs? IIRC @martinthomson suggested something similar.

Like the previous approach, that optimizes for the maintainers at the expense of every downstream build ever, which doesn't seem like a good trade-off to me.

The "separate PR" thing worked, thanks!