Hi, BTW, is LVGL going to provide a script to convert the Kconfig to a > lv_config.h of some sort? If that's the case we'll only have to call > the script after we download the tarball.
Yes, We have lv_conf_internal.h <https://github.com/lvgl/lvgl/blob/master/src/lv_conf_internal.h#L69> that translates the Kconfig values to LVGL configs. Besides, lv_conf_kconfig.h <https://github.com/lvgl/lvgl/blob/dev/src/lv_conf_kconfig.h#L13> contains some special "if"s to handle type not supported by Kconfig. The header created by Kconfig can be included here as well. See the example for ESP in the link. 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. :-) Why is it not an issue with other projects you use in NuttX? Have we missed something? Regards, Gabor Matias N. <mat...@imap.cc> ezt írta (időpont: 2020. nov. 1., V, 20:13): > 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 >
