Esp-idf: LVGL as ESP-IDF component (IDFGH-3890)

[kisvegabor]

Hi,

At LVGL we are considering making LVGL "ESP-IDF component compatible". We will add the required KConfig file, CMakeList.txt and component.mk right into the lvgl repository.

LVGL is now part of esp-iot-solution but this way it could be a 3rd party ESP-IDF component.

LVGL has a fast release cycle. We make releases every 2 weeks. If you agree with the integration on LVGL I wonder how we should update the library. Is it ok for you if we automatically send PRs every 2 weeks?

Please let me know if you like the idea and - if so - what we should take into account to make the integration easy for both parties.

cc @C47D @BFFonseca

[Alvin1Zhang]

Thanks for raising this feature request.

[igrr]

Hi @kisvegabor, is your intention to add LVGL as a submodule of ESP-IDF?

I think that if you add CMakeLists.txt/Kconfig files to LVGL, LVGL will already be useable as an ESP-IDF component. Users can simply clone LVGL into the components directory of their projects.

In addition to this approach, we are going to launch a "component manager" feature in ESP-IDF, which will allow publishing and installing 3rd party components. At the same time, we will start removing some components from ESP-IDF.

Our long term goal is to only leave essential components in ESP-IDF, to allow other components to have different release cycles. Because of longer support period requirements, intervals between ESP-IDF releases will also be becoming longer. As such, even if you update the LVGL submodule every couple of weeks, it will still be a few months before users will receive an update to the new version as part of the next ESP-IDF release.

[projectgus]

Hi @kisvegabor ,

I have a small addition to @igrr's comment, which is that we have a common "component repo" structure we use for some components distributed by Espressif outside ESP-IDF: for example the Azure SDK component.

I'm guessing you wouldn't want to place all the ESP-IDF component files into the top-level of the lvgl repo, so either a "wrapper" component repo/directory is needed or users would have to add an explicit component path to their project (something like set(EXTRA_COMPONENT_DIRS components/lvgl/esp-idf-component/))? (Please let me know if I'm wrong about this.)

To make this a little simpler we could possibly add a feature to the ESP-IDF build system so it will always check for a component in a named subdirectory as well as the top level of the component subdir (ie: Currently we expect the component to be components/COMPONENTNAME but after this change it will search the directory components/COMPONENTNAME/esp-idf-component first if it exists.) Would that be useful to make a more straightforward experience for LVGL + ESP-IDF users?

[kisvegabor]

@igrr

is your intention to add LVGL as a submodule of ESP-IDF?

Yes, this way people only need to include "lvgl.h" and don't bother with any local build settings (.e.g EXTRA_COMPONENT_DIRS).

I think that if you add CMakeLists.txt/Kconfig files to LVGL, LVGL will already be useable as an ESP-IDF component. Users can simply clone LVGL into the components directory of their projects.

Is it possible without editing any CMakeList.txt?
If so then making users manually add LVGL should work as well.

In addition to this approach, we are going to launch a "component manager" feature in ESP-IDF, which will allow publishing and installing 3rd party components. At the same time, we will start removing some components from ESP-IDF.

That's great! Do you already know when it will be released?

@projectgus

I'm guessing you wouldn't want to place all the ESP-IDF component files into the top-level of the lvgl repo

We are ok with adding Kconfig to the top-level directory as Kconfig is a general tool that comes handy on other platforms too.
However, the CMakeList file is specific to ESP-IDF and people might think it's a general CMake file. So it'd be great to keep it in a specific folder. So in our case, it would look like this:

• lvgl/Kconfig
• lvgl/esp-idf-component/CmakeList.txt

Could it also work?

Another approach could be to place the CMakeList to the top-level folder with an if(ESP_IDF_PRESENT) statement (not sure which variable to check) to allow adding multiple environments to this single CMakeList file. What do you think about it?

[igrr]

I think that if you add CMakeLists.txt/Kconfig files to LVGL, LVGL will already be useable as an ESP-IDF component. Users can simply clone LVGL into the components directory of their projects.

Is it possible without editing any CMakeList.txt?

Assuming your are asking about not editing project CMakeLists.txt file: yes, it is possible — if lvgl repository contains a component CMakeLists.txt file, and lvgl repository is cloned into project_dir/components/lvgl, then idf.py build started in project_dir will pick up lvgl component from the components directory.

In addition to this approach, we are going to launch a "component manager" feature in ESP-IDF

That's great! Do you already know when it will be released?

This week we have started adding some of our internal components to the component manager, as an experiment. If this goes smooth, I expect that within the next month we will launch the preview of the service. Can get in touch with you when this happens.

Another approach could be to place the CMakeList to the top-level folder with an if(ESP_IDF_PRESENT) statement

This sounds like a good approach — you should be able to check ESP_PLATFORM variable, it is mentioned here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html#preset-component-variables

lvgl/esp-idf-component/CmakeList.txt

one downside to this, while we can implement the esp-idf-component subdirectory logic, it will only become available in the next version in development (IDF 4.3). Whereas with an ESP_PLATFORM check in CMakeLists.txt it will work with IDF 3.3 and later.

[kisvegabor]

This sounds like a good approach — you should be able to check ESP_PLATFORM variable,

one downside to this, while we can implement the esp-idf-component subdirectory logic, it will only become available in the next version in development (IDF 4.3). Whereas with an ESP_PLATFORM check in CMakeLists.txt it will work with IDF 3.3 and later.

Great, it seems it's the best to add CMakeList.txt and Kconfig to the root of the project and use if(ESP_PLATFORM) for CMake.

And regarding the integration to ESP-IDF, we should let people add lvgl manually to their project and use the package manager when it's released.

@c47d do you also agree?

[C47D]

@kisvegabor I agree, ~does checking for ESP_PRESENT also works for the component.mk file?~

We can test checking for ESP_PRESENT on the lv_port_esp32 repo on the meantime.

[kisvegabor]

We can test checking for ESP_PRESENT on the lv_port_esp32 repo on the meantime.

Sounds good!