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 >>>> >>
