Add most common windows-bindgen options to readme

Kenny Kerr (@kennykerr)

Originally posted by Kenny Kerr (@kennykerr) in #3510_

That'd be awesome. I was just going over another crate migration to windows-bindgen and noticed that I had to backtrack from the library documentation on windows-bindgen all the way to the 0.61 release tag to find #3359 again which documents all the new options.

Would be awesome if that could be copy-pasted into docs.rs 👍

This issue is stale because it has been open 10 days with no activity. Remove stale label or comment or this will be closed in 5 days.

Kenny Kerr (@kennykerr)

Kenny Kerr (@kennykerr) has anything materialized here? Specifically, I'm curious if there's an option to generate bindings that point into windows-strings (for P(C)STR & co) which currently point to windows-core, but not sure how to set that up with --reference.

I expected something like --reference windows_strings,skip-root,Windows.Win32.Foundation.PCSTR but it can't find PCSTR in that namespace (and ilspy only shows PSTR there...?).

Been a little busy but you can get a summary of the options here: #3359

windows-bindgen assumes windows-core for the string types, but it probably makes more sense to generate those as direct dependencies on windows-strings. Just for context, is there a reason you'd like to avoid the windows-core dependency?

That's the PR I had been looking at, but iirc some things changed since (--no-deps is new iirc, and not documented there).

I don't necessarily need to get rid of windows-core, but a vocal minority at iana-time-zone wants it (requiring use of more complicated and less portable APIs while at it).

Perhaps having a mode where we can pick which crate to use would be useful. For example, --no-deps + --sys generates bindings against windows-link with an MSRV of 1.71. If I want to opt out of that by removing --no-deps to go back to windows-targets dependencies, the PCSTR typedef is replaced with windows_sys::core::PCSTR too :)

#3450 added the --link option that you can use to control whether it uses windows-link, windows-targets, or something else.

The strings are a bit more complicated but I'll give that some more thought.

Thanks, that's exactly what I need! Looks like it's available in both windows-bindgen 0.60 and 0.61 too 👍

Sorry for the delay: #3617

Kenny Kerr (@kennykerr)

Hey Kenny Kerr (@kennykerr), is any documentation available on how to replace a windows-core dependency with windows-result (the code I'm generating only references windows_core::Result)? Likewise, it was possible to ask the generator to inline BOOL too, right?

I feel like I've asked both questions before, but can no longer find them nor the answers. Thanks! 🙏

That's hardcoded as Result is not part of the metadata but I have been meaning to redirect that to windows_result instead to avoid the dependency on the larger windows-core crate where practical. Anything to do with COM will still have a dependency on windows-core however. See #3753

For BOOL I think --no-deps should do the trick.

https://docs.rs/windows-bindgen/0.63.0/windows_bindgen/fn.bindgen.html

but I have been meaning to redirect that to windows_result instead to avoid the dependency on the larger windows-core crate where practical. [...] See #3753

That's nice, thanks! On the other hand, it does throw me back to some other crates where, despite already having the windows crate, we also needed to include windows-core as an explicit dependency for a few specific references (iirc from within a macro, not sure). I remember finding this tedious back in the day, and maybe that's worse if crates generated from windows-bindgen have to include all these special crates (-strings, -result, -collections...) if they already have windows-core and/or windows. Not sure if it should be controllable explicitly per-crate in bindings.txt?

Anything to do with COM will still have a dependency on windows-core however.

Yep, of course. The mean reason to change these things is because I keep running around more and more crates that need windows or windows-core updates each time a new breaking release is published to keep duplicates down.

For BOOL I think --no-deps should do the trick.

I tried that on Xudong-Huang/generator-rs#76 after backtracking that --no-core was renamed to --no-deps, but it doesn't seem to make a difference without --sys, as I wanted to have the high-level Result type.

With --sys, adding --no-deps replaces windows_sys::core::BOOL with a new type BOOL definition in the root of the generated module.

Navigation Menu

Repository navigation

Add most common `windows-bindgen` options to readme #3514

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add most common windows-bindgen options to readme #3514

Description

Activity

MarijnS95 commented on Mar 4, 2025

github-actions commented on Mar 20, 2025

MarijnS95 commented on Apr 16, 2025

kennykerr commented on Apr 16, 2025

MarijnS95 commented on Apr 16, 2025

kennykerr commented on Apr 16, 2025

MarijnS95 commented on Apr 17, 2025

kennykerr commented on Jun 2, 2025

MarijnS95 commented on Sep 9, 2025

kennykerr commented on Sep 9, 2025

kennykerr commented on Sep 9, 2025

MarijnS95 commented on Sep 9, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Add most common `windows-bindgen` options to readme #3514