When using lv_micropython based firmware, REPL reports an old version of Micropython while the code is up to date.
Reason for this is the command ‘git describe’, which is used by the script makeversionhdr.py.
‘git describe’ itsself echos the newest tag avaliable, which is in this case an old one.
I watched some videos about git online and it may be I found a clue to the ‘git describe’-effect in the
lv_micropython repo, which reports the wrong version of micropython.
This may be the result of using ‘git add submodule’ in a repo, which then “fixed” and get no more updates even when doing a git pull in the parent repo.
One needs to do a git checkout of a specific version of that submodule to get an update and getting all metadata updated as far as I understood the underlying mechanics.
I will try to follow that path (I git submodule added lv_bindings_micropython into my local micropython repo) – I am waiting for updates of the according repos online to check that.
Would it be possible that this mechanics may also apply to the lv_micropython repo online?
I don’t think submodules is the issue.
Micropython is not a submodule of lv_micropython, it’s a fork.
I think the problem is somehow related to git tags. I noticed that some ports (for example the unix port) report the correct versions while others (such as the ESP32 port) don’t.
in the root of the micropython, which gave me the current valid version (tag) of cloned mycropython repo. Then I had to wait for a change in mycropython repo on github, which happens this morning (or better: I recognized it this morning )
I did a
in the root of the directory mentioned above and then a
and VOILA! the output has changed to reflect the update.
reports all (or better: it looks like that) tags, which consists of the versions of micropython so far.
Then I changed to the subdirectory ./lib/lv_bindings and did a
which gave no output. Changeing to ./lib/lv_bindings/lvgl and repeating the command gave me a list of versions of lvgl so far.
which is different from that I got above. Assuming that the lvgl inside lv_micropython_binding and lvgl itsself are of the same version, I am still a little confused here…which nonetheless may be the result of my still incomplete knowledge of the deeper mysteries of git.
I still don’t understand why you didn’t fork lv_micropython as your starting point.
That would have made your life easier. Also, when I would make changes to lv_micropython in the future you would have harder time integrating them into your own micropython fork since it’s not an lv_micropython fork.
As @embeddedt explained, submodules don’t update automatically.
This is the idea in git submodules, you select a specific version of the remote repository and set your submodule to “point” to it. We wouldn’t want a change in LVGL to break lv_micropython spontaneously.
To update lv_micropython I usually follow these steps:
cd to the LVGL submodule, and pull the newer version
cd to the lv_binding_micropython submodule and diff lv_conf.h and lv_conf_template.h. Changes in the template usually (but not always) require fixing the lv_conf.h in lv_binding_micropython.
Add, commit and push the LVGL submodule and lv_conf.h in lv_binding_micropython submodule.
cd to lv_micropython root, build and test. In certain cases I would need to fix some things.
Add commit and push the lv_binding_micropython submodule, and possibly other changes.