Closed hmmkay closed 3 years ago
Hi @hmmkay !
Checking out the dev-8.0 branch and directly executing make from the ports/esp32 directory gives a compile error which I believe I've tracked down to the lv_conf.f from commit d7f2aabfe missing a typedef for the lv_coord_t type.
I suspect this is a local problem in your workspace.
Did you forget updating submodules recursively? (git submodule update --recursive --init
)
Did you try to clean and rebuild?
Maybe some other git problem? Did you try to reproduce this by cloning a fresh repo?
I 'fixed' this by copying over the default lv_conf.h with lv_conf_template.h, which led me to Problem 2 where I'm currently stuck ...
I'm trying to keep lv_micropython
in a healthy state, compiling and running, for both the unix port and ESP32 port.
I'm not familiar with any special "fixes" that are required in order to compile and run these ports.
If there's an easier/alternate way to get micropython >+1.14 and lvgvl >+ 7 compiled with CMake I'd be happy to be pointed in that direction. The dev-8.0 branch of lv_micropython looked to be the best path to follow for that.
The dev-8.0 is the right path, and it will be merged into main branch in the near future.
Thanks for the reply.
Yes, the steps I showed to reproduce Problem 1 start with a clean git clone of lv_micropython.
I am using --recurse-submodules on this initial clone, so perhaps there's some difference that I didn't realize between doing in this way and as a separate 'submodule update --recursive --init' after the fact - I'm busy taking a look to see if that's the problem.
It's good to know it works on your setup - I'll keep plugging away to see what is wrong my end then come back and close this issue with the resolution.
Also - please make sure you have up-to-date CMake. I'm using cmake 3.18.4.
Yes. The version that I show in my reproduction is 3.20.3. I tried different versions of the IDF without success (but think I had different issues if I recall even though I tried to stick to those that micropython is known to work with)
Okay, umm, after running 'submodule update --recursive --init' it does in fact now compile.
I am now feeling embarassed because I suspect I've misunderstood something basic about how submodules work. I'll try reproduce where I've gone wrong and post the results back here for any future soul that follows my misguided journey :)
Thanks for the assistance.
So for the next person who wanders down this path, the issue was my misunderstanding of switching branches when git submodules are involved:
When I switched to the dev-8.0 branch of lv_micropython and also switched to the dev-8.0 branch of lib/lv_bindings (something I left out in my original Problem 1 steps) then my local repo was still pointing to the commits required by the master branch for the lvgl, pycparser and driver/png/lodepng submodules, instead of those required by the dev-8.0 branch.
ie:
hmmkay@hmmkay ~/repro2/lv_micropython/lib/lv_bindings (master)$git checkout dev-8.0 <-- I'm on the master branch of the lv_bindings submodule, switching to the dev-8.0 branch to get the CMake goodness
M driver/png/lodepng
M lvgl
M pycparser
Switched to branch 'dev-8.0'
Your branch is up to date with 'origin/dev-8.0'.
hmmkay@hmmkay ~/repro2/lv_micropython/lib/lv_bindings (dev-8.0)$ git submodule <-- this tells me what submodules are downstream from this point and what commit they're currently checked out at
+2e541f53ebedf6ebae375a381ca2fd6d82b460bc driver/png/lodepng (2e541f5) <---- outdated commit (used by master branch)
+b16e7f1076963f123b36dec9ce1dd5950057ca1a lvgl (v7.11.0-34-gb16e7f10) <--- outdated commit (used by master branch)
+e1a1d737be66308b633215fa26ac5ed30e890103 pycparser (release_v2.19-13-ge1a1d73) <--- outdated commit (used by master branch)
If I executed the 'git submodule update --recursive --init' command as amirgon suggested, then suddenly my repo pointed to the correct commits of the various submodules like so:
hmmkay@hmmkay ~/repro2/lv_micropython/lib/lv_bindings (dev-8.0)$ git submodule update --recursive --init <-- change the submodules to the commits needed by this parent
Submodule path 'driver/png/lodepng': checked out '7fdcc96a5e5864eee72911c3ca79b1d9f0d12292'
Submodule path 'lvgl': checked out '29bfe60438a46342bcd99a7ff57939a7a508ed03'
Submodule path 'pycparser': checked out '1706a39e0116dde0b2d1c52d67078a9a0ab4dbe7'
hmmkay@hmmkay ~/repro2/lv_micropython/lib/lv_bindings (dev-8.0)$ git submodule
7fdcc96a5e5864eee72911c3ca79b1d9f0d12292 driver/png/lodepng (heads/master) <-- different commit
29bfe60438a46342bcd99a7ff57939a7a508ed03 lvgl (v8.0.0-3-g29bfe604) <--- now we're using the correct version of LVGL and my compilation errors go away! Yay!
1706a39e0116dde0b2d1c52d67078a9a0ab4dbe7 pycparser (release_v2.20-27-g1706a39) <--- different commit
So today I learned with git that when you checkout different branches that involve sub-modules, the sub-modules are not automatically switched to the right commit reference the way I assumed they were - you need to manually run the submodule update command to update the sub-modules to the correct commits required by the parent.
Hi,
I have an ESP32 board and want to compile micropython using Cmake going forward. Thankfully Cmake support was just added in micropython 1.15, so now I'm wanting to add lvgl as a micropython module - which looks like it should be possible per the dev-8.0 branch of lv_micropython. However I'm having some trouble compiling this branch:
Problem 1 Checking out the dev-8.0 branch and directly executing make from the ports/esp32 directory gives a compile error which I believe I've tracked down to the lv_conf.f from commit d7f2aabfe missing a typedef for the lv_coord_t type.
I 'fixed' this by copying over the default lv_conf.h with lv_conf_template.h, which led me to Problem 2 where I'm currently stuck ...
Problem 2 - I copied the config template lv_conf_template.h over lv_conf.f (noting that the template still talks about being for 7.11.0 whereas lv_conf says its for 8.0), and set #if 1 ...
hmmkay@hmmkay ~/repro/lv_micropython/ports/esp32 (dev-8.0)$ cp ../../lib/lv_bindings/lvgl/lv_conf_template.h ../../lib/lv_bindings/lv_conf.h
... but now I get stuck with a trickier problem that after executing make with the new lv_conf.h file, the gen_mpy.py script can't seem to lookup a key called lv_mem_buf_arr_t. This requires more understanding than I currently have to correct since I don't understand (and honestly don't want to :D) how this script does its magic. I've twiddled some of the memory settings in lv_conf.h in the hope that perhaps changing how memory management is configured that I can move past this error, but no luck so far.
Enabling -v debug for the ESP IDF in the Makefile wrapper gives me the following command as the one that fails when running make:
--
If there's an easier/alternate way to get micropython >+1.14 and lvgvl >+ 7 compiled with CMake I'd be happy to be pointed in that direction. The dev-8.0 branch of lv_micropython looked to be the best path to follow for that.
Any assistance in moving forward would be appreciated! Thanks in advance.