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. <[email protected]> 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. <[email protected]> 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
>>
