Sebastian Dröge
Sebastian Dröge
It would be better if the code generated by the macro would reference the hawktracer API via absolute path instead of depending on it to be in scope.
Allows us to get rid of some heuristics
Hi, thanks for your effort to create these bindings. For the long run it will be much less maintenance work for you to have them autogenerated from the GObject-Introspection information...
You might want to take a look at https://github.com/sdroege/rsplugin/blob/master/gst-plugin/src/buffer.c and https://github.com/sdroege/rsplugin/blob/master/gst-plugin/src/miniobject.rs . I'm implementing the miniobject COW via something Arc-style. With that you will only ever be able to get...
Examples of this would be e.g. the whole zoo of libraries Windows ships, like `bcrypt.dll` or `kernel32.dll` (the latter is already pulled in by `std` of course). Having these listed...
This could then be used to run things like `sdl2-config`, and similar to retrieve the same information. Crates could provide code to extract these things and then provide the same...
See https://www.reddit.com/r/rust/comments/86kmhu/compiling_rust_windows_gtk_stepbystep/ for a good start
See https://github.com/gtk-rs/sys/pull/119 for a start Without this we currently have no tests at all for the bitfield support, so should fix that as soon as possible.
``` warning: trait `FooExt` is never used --> glib-macros/tests/test.rs:286:19 | 286 | pub trait FooExt: IsA + 'static { | ^^^^^^ | = note: `#[warn(dead_code)]` on by default warning: `glib-macros`...