Progress on lv_cxx_bindgen

[voltangle]

It's just that I started work on my implementation of a C++ binding generator, soo I would like to know if someone is already working on this, so that I can know if I should still continue work on mine
Current progress is an implemented extractor of functions from .h files, and an abstract source code tree (a representation of all binding parts in memory) generator in progress.

[kisvegabor]

It's just that I started work on my implementation of a C++ binding generator

A generator would be great! Mostly I have seen only hand written C++ bindings.

As far as I know no one is actively working on it now. Please keep us posted about the progress.

[voltangle]

If you're interested, here's a link to the repo: https://github.com/dynamium/lv_cxx_bindgen

[xinsuinizhuan]

I plan to work with this. So recommended to update the lvgl code to the latest version

[kisvegabor]

I agree to this based on LVGL v9 (in current master). @kdschlosser is working on a simple JSON file containing the whole LVGL API in an easy to digest form. I hope it will go public soon.

[voltangle]

Now that sounds good! Because right now parsing all the source code is pretty hard to do right, especially with all the macros ngl
Oh, and yes, if that JSON file becomes a thing, the generator can support both source code parsing and JSON, or better yet, have it separated into two utilities, the one that parses header files and extracts everything into a JSON file, and the one that generates all the bindings from the same JSON file

[kisvegabor]

See the discussion about the JSON file here: 5168

[gjvanderheiden]

I am! Got it working for version 8 en 9 with examples. Replace the lvgl dir with your fav. version. Generates with Python.

https://github.com/gjvanderheiden/lv_binding_cpp

This is weeks of work. I needed it to develop my own project.

[gjvanderheiden]

The only caveat is order of deletion, because the c lib deletes it's child objects.

This is all fine, as long as you declare your object in the same order as creation. Assuming you're not using raw pointers. (Then delete in the reverse order). Also tried to add a check, worked also, but wasn't sure about it being better

[kisvegabor]

Hi @gjvanderheiden,

Thank you for jumping in! It's great now we have 2 people working on it.

I suggest figuring out what the advantages of yours and @ggoraa's implementation are and try to unify them.

[kisvegabor]

I think the JSON file proposed in lvgl/lvgl#5168 shall be used in the end so that the bindings can work from a common source.

[gjvanderheiden]

Sorry, I don't intend to redo my idea for a first version. I deleted my fork on GitHub.

I'm sorry, but my project is done as version 1. I've put many many many hours in the bindings and it is fully working for version 8 en 9, has examples, can wrap structs with assessors to name a few features. I did this in my own time. I'm talking about weeks full time. I wrote it, so I'm the owner of my code. Not to say I'm not open for suggestions, modifications, improvements. More to say I ment it as a take or leave over as is first version.

It could use json in the future, but now it's working. It also parses the #if LV_USE_... statements around the methods. It also parses comments and detects and removes the C-object parameter as It is even uncertain of json could provide the level of detail I'm doing in my version.

I wish good luck to the project.

[kisvegabor]

I'm sorry to hear that. All I wanted to say is that we are smarter together and we can discuss how to do things better.

[voltangle]

By the way, is the reward still a thing? :D

[kisvegabor]

Sure, it is! 🙂