Hi Alan, On Sun, Nov 1, 2020, at 14:52, Alan Carvalho de Assis wrote: > Since we will download the LVGL tarball with a Kconfig, we cannot > display the menuconfig before it is downloaded and decompressed. > And because its download depends on selected item on menuconfig we a > classic dilemma here. :-)
Yes, I understand the problem. > > An option could be including a Kconfig in apps/graphics/ that just let > the user to enable to Kconfig, and then during the building process > after the download and decompress of the lvgl.tar.gz the menuconfig is > called just to let the user to fine tune the LVGL configuration. This > is just an idea, because currently we do all the configuration in a > single step, but breaking down this process in two phases we could > simplify this kind of issue. Probably this idea could get some > resistance, what do you think? Well, I was just arguing against this strategy exactly (or anything changing our standard configuration workflow). Having two separate configuration processes, added targets, extra config file, is all just added complexity for no good reason. I don't see how this helps us at all. The current process of configuring LVGL from a submenu of our config is the best approach. What I suggested is to ship LVGL's *official* Kconfig file as part of our repo. Compared to our current approach, we would use an official solution which we know works for the LVGL version we are using. Moreover, we build not be maintaining this file, it would be maintained by LVGL. We would just download it whenever we decide to upgrade to another LVGL release. Note the comment from Zephyr guys on this (last line): https://github.com/lvgl/lvgl/pull/1875#issuecomment-720086968 They essentially do what I'm suggesting. > > BTW, if LVGL projects just create a Kconfig similar to > apps/graphics/lvgl/Kconfig already will help because, because until > now for each LVGL release we need to create a new Kconfig. That is exactly my point in how the above approach would indeed benefit us (instead of us just having to complicate our configuration/build system). Best, Matias
