Comments (4)
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.
from gdext.
Yes, there would still need to be an option to generate bindings in godot-ffi
, also for CI to verify that the binding is up-to-date.
What I could imagine is something similar to the custom-godot
feature in GDNative: by default, we support the latest Godot version out-of-the-box, and allow customization via feature flag (which would pull and run bindgen
). We could even verify at build time that the Godot engine version in PATH is the same as the one for which bindgen
was run, and throw an error otherwise.
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 master
, and issue a warning (but no error) if someone uses an older version. That way, people can decide themselves whether they want to take the risk.
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!
from gdext.
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.
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
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.
from gdext.
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.
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.
from gdext.
Related Issues (20)
- Type-safe API to query Godot features HOT 2
- Extension class instances constructed in rust cannot be reloaded HOT 1
- `#[derive(GodotClass)]` on tuple structs should fail before other macro failures HOT 4
- `Engine::register_singleton` corrupts object ref count HOT 3
- `GodotClass`: user vs. library items, characteristics and orthogonality
- Improvements with Godot classes for better templating HOT 3
- Make `ScriptInstance.call` and company re-entrant HOT 15
- ScriptLanguageExtension methods can be called from multiple threads HOT 2
- Support using `Base` for initialization in `init` function HOT 7
- Impl `Iterator::size_hint()` for `Dictionary` iterator types HOT 3
- Support every class-registration option that Godot offers HOT 1
- AutoLoaded scenes through an EditorPlugin GodotClass are not added the scene of the editor node tree HOT 7
- Module `convert_error` is private HOT 2
- GDExt panics when two structs from different modules are named the same HOT 1
- `Gd<Self>` return type causes type error when fn annotated with `#[func]` HOT 2
- Implement (or derive) GodotType for godot compatible repr enums HOT 2
- Godot editor crashes when hot reloading gdext library with custom resources HOT 6
- Import Godot docs for builtin types HOT 7
- No recommended way to call `Base<T>` methods from `init` HOT 2
- Single- and multi-threading support for `Callable::from_fn` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gdext.