Sure, thank you too for your support! :) Regards, Gabor
Matias N. <mat...@imap.cc> ezt írta (időpont: 2020. nov. 3., K, 14:48): > Great, I just added a comment there. > Thank you very much for collaborating with us to find the best solution > for both projects. > > Best, > Matias > > On Tue, Nov 3, 2020, at 10:41, Gábor Kiss-Vámosi wrote: > > Hi Matias, > > The "include" is added here: > https://github.com/lvgl/lvgl/blob/dev/src/lv_conf_kconfig.h#L18-L20 > > It under consideration here: https://github.com/lvgl/lvgl/pull/1875 > Could you write a comment there to let people know you vote for a single > file? > > Regards, > Gabor > > > > Matias N. <mat...@imap.cc> ezt írta (időpont: 2020. nov. 2., H, 14:47): > > > Hi Gabor, > > we just recently added a __NuttX__ macro as part of our base compilation > flags, so I guess it should be: > > #ifdef __NuttX__ > #include <nuttx/config.h> > #endif > > What do others think? > > BTW, are you thinking of a single root Kconfig or a series of nested > Kconfigs? The latter would be a bit more difficult to handle the way I > suggested. > > Best, > Matias > > On Mon, Nov 2, 2020, at 10:43, Gábor Kiss-Vámosi wrote: > > I see, thanks for the explanation. > > I understand that we can consider each project to be configured > separately, but IMHO it would be great if we could just > use your Kconfig files as part of Kconfig system (having the Kconfig files > downloaded previously, as I suggested). If your internal headers assume > that each symbol will be translated to CONFIG_<symbol> and if you allow for > an external header to be included ("#include <nuttx/config.h>") via some > symbolic link, dummy file or macro, NuttX would supply the macros generated > during our configuration stage. > > > > Seems clear from our side. Please let me know what snippet I should for > NuttX. Similar to: > #if defined ESP_PLATFORM > #include "sdkconfig.h" > #include "esp_attr.h" > #endif > > Regards, > Gabor > > > Matias N. <mat...@imap.cc> ezt írta (időpont: 2020. nov. 2., H, 14:33): > > > On Mon, Nov 2, 2020, at 09:51, Gábor Kiss-Vámosi wrote: > > 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. > > > I understand that we can consider each project to be configured > separately, but IMHO it would be great if we could just > use your Kconfig files as part of Kconfig system (having the Kconfig files > downloaded previously, as I suggested). If your internal headers assume > that each symbol will be translated to CONFIG_<symbol> and if you allow for > an external header to be included ("#include <nuttx/config.h>") via some > symbolic link, dummy file or macro, NuttX would supply the macros generated > during our configuration stage. > > > 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? > > > Well, that is why it would be "awkward" as others mentioned: no other > project we depend on AFAIK is based on Kconfig. And for projects requiring > some different configuration stage, we apply some patch (not ideal) to add > NuttX support. So, our build system is very simple: > > - initialize based configuration for board-config combination (using own > script, which setups build environment and places initial .config) > - make menuconfig > - make > > During make there's a "context" stage which downloads all third-party > tarballs and extract them. > > Best, > Matias > > > 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 > > > >
