'get describe' reporting the wrong version of micropython for lv_micropython

Micropython
1

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?

Cheers!
mcc

2

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.

Related GitHub issue:

3

Hi Amirgon,

I have built “my own” lv_microphyton on my local harddisk (that is: not on github) and followed the
instructions given closely.
Regarding actions done with the git command I first did a

git clone --recurse-submodules 'https://github.com/micropython/micropython'

and then a

git submodule add https://github.com/lvgl/lv_binding_micropython lib/lv_bindings

and then I did a

git describe

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 :slight_smile: )

I did a

git pull

in the root of the directory mentioned above and then a

git describe

and VOILA! the output has changed to reflect the update.
Additonally a

git tag

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

git tag

which gave no output. Changeing to ./lib/lv_bindings/lvgl and repeating the command gave me a list of versions of lvgl so far.

git describe

gave me: v7.7.0-16-g4dafa100
BUT! After a

git pull

this output was given:

   8a489b3a..3e404b15  dev        -> origin/dev
   92c23bab..d06aa859  dev-v8     -> origin/dev-v8
   b19fb862..43771fa2  master     -> origin/master

(beside other stuff not related)

and

git describe

doesn’t change.

Then I clones lvgl and separatly:

git git clone --recurse-submodules 'https://github.com/lvgl/lvgl.git'

and check with

git describe

and got

v7.7.1-13-g43771fa2

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. :wink:

Cheers!
mcc

4

The LVGL version inside lv_binding_micropython does not automatically synchronize with upstream, so it will generally be slightly behind till @amirgon pushes another update.

5

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.