lv_binding_rust
lv_binding_rust copied to clipboard
lvgl
Move `lvgl-sys` to a separate repository.
Since lv_binding_rust appears unlikely to be updated for LVGL v9.X anytime soon, could lvgl-sys be moved to a separate repository to allow for regular updates independently of lv_binding_rust/lvgl?
I already have a repository ready, we just need to change ownership, do some tweaking and refactoring in the build script and add automatic release for previous versions (down to v8.0.0 ? maybe).
Hi,
If a user wants to use the lvgl rust bindings what should they include, this repo or the lvgl-sys repo?
I have the impression that this repo is more an examples repo and moving lvgl-sys to a separated repo sound like a good thing to do. I guess we should also need update it when main lvgl make a new release. Am I missing something else?
Any thoughts @kisvegabor?
Regular end users should rely on the safe Rust bindings. However, advanced users might choose to use the unsafe raw bindings (via the lvgl-sys C library generated by bindgen), either as a complement (to use API unsupported by the safe one) or directly, depending on their needs.
The release schedule for the repositories should be as follows:
- Raw (
lvgl-sys): Automatically (CI) released whenever a new version of LVGL is released (major, minor, or patch). - Safe bindings: Released when ready, typically aligned with major LVGL versions. The
lvgl-sysdependency version should be set to any minor or patch updates, as these do not introduce breaking API changes, thus no change in the safe part code generator.
So you are mostly right, I added that for precision purpose.
Regular end users should rely on the safe Rust bindings. However, advanced users might choose to use the unsafe raw bindings (via the
lvgl-sysC library generated bybindgen), either as a complement (to use API unsupported by the safe one) or directly, depending on their needs.The release schedule for the repositories should be as follows:
- Raw (
lvgl-sys): Automatically (CI) released whenever a new version of LVGL is released (major, minor, or patch).- Safe bindings: Released when ready, typically aligned with major LVGL versions. The
lvgl-sysdependency version should be set to any minor or patch updates, as these do not introduce breaking API changes, thus no change in the safe part code generator.So you are mostly right, I added that for precision purpose.
And the safe bindings are this repo? They have to be done manually? Sorry for the dumb questions tho
Don't worry. This repository currently includes both the safe and unsafe bindings. The safe bindings are generated using the lvgl-codegen lib (check its folder) which takes the raw unsafe bindings (lvgl-sys) and generate safe / rust idiomatic bindings (check the build.rs script in the lvgl folder). If we separate out the unsafe bindings, what remains will be the generated safe bindings (lvgl) and their generator library (lvgl-codegen).
It might be a little off topic, but also related to the schedule of the releases and stability. In the the lvgl repo we have a test which should be added for all bindings. This UI needs to be created. This is the C code. For MicroPython we have the equivalent test which uses the very same reference image. Both test are part of LVGL's CI so we test MicroPython on each commit.
In order to support Rust in a serious level we need to add a similar test to make sure that the binding is not broken.
What do you think about it?
It might be a little off topic, but also related to the schedule of the releases and stability. In the the lvgl repo we have a test which should be added for all bindings. This UI needs to be created. This is the C code. For MicroPython we have the equivalent test which uses the very same reference image. Both test are part of LVGL's CI so we test MicroPython on each commit.
In order to support Rust in a serious level we need to add a similar test to make sure that the binding is not broken.
What do you think about it?
Sounds like a good first step to keep this binding working. I will travel tonight back to home, so I can work on this this weekend
It might be a little off topic, but also related to the schedule of the releases and stability. In the the lvgl repo we have a test which should be added for all bindings. This UI needs to be created. This is the C code. For MicroPython we have the equivalent test which uses the very same reference image. Both test are part of LVGL's CI so we test MicroPython on each commit.
In order to support Rust in a serious level we need to add a similar test to make sure that the binding is not broken.
What do you think about it?
Yeah that makes sense and it is easy to implement. However there is some stuff like img in this test that wasn't supported before so I don't expect it to fully pass anytime soon.
@kisvegabor With regards of separating the lvgl-sys repo from this, do you agree, see any issue?
However there is some stuff like img in this test that wasn't supported before so I don't expect it to fully pass anytime soon.
That binding test is quite complete. If he binding is capable of doing all these, most of the people should be happy with it. So I think it's also good measure for readiness.
With regards of separating the lvgl-sys repo from this, do you agree, see any issue?
Basically there would be 2 bindings: a safe and an unsafe? If so, I suggest focusing on the simpler first, and if it ready, working, and we have positive feedback, we can create a repo for the other too. What do you think?
Basically there would be 2 bindings: a safe and an unsafe? If so, I suggest focusing on the simpler first, and if it ready, working, and we have positive feedback, we can create a repo for the other too. What do you think?
Correct, the unsafe bindings (located in lvgl-sys) are created automatically, but having lvgl-sys in a separated repo would allow us to generate unsafe bindings for multiple LVGL versions. Currently the unsafe bindings available in this repo are 'stuck' in LVGLv8.
See this another comment about it https://github.com/lvgl/lv_binding_rust/issues/158#issuecomment-2579169093
What about using branches like release/v8.3, release/v8.4, release/v9.0, etc?
Same as we do in the lvgl repo?
What about using branches like
release/v8.3,release/v8.4,release/v9.0, etc? Same as we do in thelvglrepo?
Exactly
Ok then, I'll create a new branch with the current version and then move the lvgl submodule to v9, then we can start patching it as @AlixANNERAUD did in their repo. Does that sound ok?
I've just created the release/v8.3 branch, does it sounds ok? If so I can create new branches with all the other releases taking the main LVGL repo as reference.
I've just created the
release/v8.3branch, does it sounds ok? If so I can create new branches with all the other releases taking the main LVGL repo as reference.
In the current repository ? I meant to create a separate repository + synced branch with upstream LVGL for lvgl-sys.
I think @kisvegabor is more in favor of having it in the same repo. Having lvgl-sys (a.k.a. FFI bindings) will allow us to include them without all the other bindings, isn't?
The main point of my original issue is that moving lvgl-sys to a separate repository would give users the flexibility to choose between the unsafe bindings or the full-fledged safe bindings in Rust.
The current proposal is impractical and confusing, as it requires maintaining a compatible version of the safe lvgl bindings for each version of the lvgl-sys bindings, which is hardly achievable since safe bindings would require adaptation for future release (e.g. the current v9).
Decoupling the two would simplify this process, allowing users to choose more easily and enabling lvgl-sys bindings to be released promptly whenever a new LVGL version is available since it is automatically generated and would not require adaptation for any future release (since raw C to rust bindings generation are stable).
This approach mirrors the structure of the LittleFS Rust bindings, where the safe bindings are hosted in one repository and the unsafe bindings in another, providing a clear and modular separation.
If after that you still think that using the same repository is a good idea, we can move on anyway.
Any updates @kisvegabor ? I see the LittleFS repo as a good example on how splitting both bindings in separated repos is useful
Sorry for the delay. 🙁
I'm ok with having 2 repos for the safe and unsafe binding as it seems they are really separate things (different code base, different issues, different versioning). However for versions I think we should use the branches as it was proposed by @C47D I can't comment on the Rust related details , but having a repo for each version would make the lvgl GitHub organization nosiy.
I can't understand why you are saying "noisy" @kisvegabor, i have looked into the organization and its already pretty much exactly noisy, i have no clue what doing this is changing, seems just like moving goal posts.
It has been several months, maintainers are waiting to actually do work, don't block the flow.
Sorry for the delay. 🙁
I'm ok with having 2 repos for the safe and unsafe binding as it seems they are really separate things (different code base, different issues, different versioning). However for versions I think we should use the branches as it was proposed by @C47D I can't comment on the Rust related details , but having a repo for each version would make the lvgl GitHub organization nosiy.
