Pre-generate bindgen file #12
Comments
Bromeon
added
quality-of-life
|
you'd need to version them per release version; I've found that even patch number updates can introduce breaking changes (semver not withstanding). This also wouldn't work with custom builds, like Godot versions with Steam integration built in. |
|
Yes, there would still need to be an option to generate bindings in What I could imagine is something similar to the This is a bit a mess during Godot 4 beta, as I'd like to use nightly Godot builds for CI (changing every day), and then every single version is possibly breaking. Maybe a compromise would be to always support latest Godot nightly on A very involved approach is to maintain a list of all nightly versions since the last time the binding headers changed, and check if Godot in PATH is one of them. This would be quite some effort, and still not work of Godot is newer than godot-rust, or of a version between those that were used for nightly builds. So many options... 😅 I'm open for input! |
|
IMO, it’s not worth the effort to try and support people developing on top of the current master. If they’re doing that, then they likely have LLVM already installed (or know how to do it easily). I’d recommend only keeping the official beta releases as the prebuilt ones and if users have something else, throw an error and tell them they need to use bindgen by compiling with a feature flag or something.
lord, tell me about it. I developed on top of master for a year and a half, and it was a pain in the ass. What I did was I had the main CI workflow pinned to the last good commit, and I had a separate workflow that ran on a timer that just compiled to see if I had drifted out of sync. |
Yeah, maybe "support latest Beta release out of the box" might be a good policy. We can still run CI additionally against Godot nightly builds, maybe in a way that allows failing, to learn about potential changes sooner. |
# This is the 1st commit message: Parse gdextension_interface.h declarations using regex # This is the commit message #2: AsUninit trait to convert FFI pointers to their uninitialized versions # This is the commit message godot-rust#3: GodotFfi::from_sys_init() now uses uninitialized pointer types # This is the commit message godot-rust#4: Introduce GDExtensionUninitialized*Ptr, without changing semantics # This is the commit message godot-rust#5: Adjust init code to new get_proc_address mechanism # This is the commit message godot-rust#6: Make `trace` feature available in godot-ffi, fix interface access before initialization # This is the commit message godot-rust#7: Compatibility layer between Godot 4.0 and 4.1 (different GDExtension APIs) # This is the commit message godot-rust#8: Add GdextBuild to access build/runtime metadata # This is the commit message godot-rust#9: Detect 4.0 <-> 4.1 mismatches in both directions + missing `compatibility_minimum = 4.1` # This is the commit message godot-rust#10: Detect legacy/modern version of C header (also without `custom-godot` feature) # This is the commit message godot-rust#11: CI: add jobs that use patched 4.0.x versions # This is the commit message godot-rust#12: Remove several memory leaks by constructing into uninitialized pointers # This is the commit message godot-rust#13: CI: memcheck jobs for both 4.0.3 and nightly # This is the commit message godot-rust#14: Remove ToVariant, FromVariant, and VariantMetadata impls for pointers This commit splits SignatureTuple into two separate traits: PtrcallSignatureTuple and VarcallSignatureTuple. The latter is a child of the former. PtrcallSignatureTuple is used for ptrcall and only demands GodotFuncMarshall of its arguments. VarcallSignatureTuple is used for varcall and additionally demands ToVariant, FromVariant, and VariantMetadata of its arguments, so pointers cannot benefit from the optimizations provided by varcall over ptrcall. # This is the commit message godot-rust#15: Adds FromVariant and ToVariant proc macros # This is the commit message godot-rust#16: godot-core: builtin: reimplement Plane functions/methods # This is the commit message godot-rust#17: impl GodotFfi for Option<T> when T is pointer sized and nullable godot-rust#240 Additionally FromVariant and ToVariant are also implemented for Option<Gd<T>> to satisfy all the requirements for ffi and godot_api. # This is the commit message godot-rust#18: Fix UB in virtual method calls that take objects Fix incorrect incrementing of refcount when calling in to godot Fix refcount not being incremented when we receive a refcounted object in virtual methods # This is the commit message godot-rust#19: fix UB caused by preload weirdness # This is the commit message godot-rust#20: Implements swizzle and converts from/to tuples
Bindgen not only adds a ton of dependencies that slow down initial compilation, but it is regularly an obstacle for users to get started, because they don't have LLVM installed or correctly configured.
We could generate the bindings Rust file on developer machines and ship it. CI could be used to enforce that bindings are up-to-date.
If it turns out that different platforms have different binding files, conditional compilation is an option. Would add a bit of development of maintenance effort, but probably worth the easier and faster setup process for everyone.
The text was updated successfully, but these errors were encountered: