You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Brennan Ashton <ba...@brennanashton.com> on 2020/11/01 01:04:00 UTC
Re: LVGL moving to Kconfig, how we could integrated better with them
I'm confused how this would work. Don't you need to download the source
tarball which is controlled via kconfig before you could source it?
Every other system I have used that does this has you supply the defconfig
to the top level build system. It you want to change settings you would do
make lvgl-menuconfig
make lvgl-savedefconfig
And the save the updated defconfig.
So you might have
boards/sim/sim/config/LVGL/defconfig
boards/sim/sim/config/LVGL/lvgldefconfig
The NuttX config would contain
LVGL_DEFCONFIG="boards/sim/sim/config/LVGL/lvgldefconfig"
This is how you handle the Linux kernel or uboot in Buildroot.
On Sat, Oct 31, 2020, 4:24 PM Matias N. <ma...@imap.cc> wrote:
> But isn't the point that we would just source their Kconfig?
> What I mentioned previously is that maybe it can be done so that
> they can accept an external header providing the Kconfig defitions
> (in our case nuttx/config.h).
>
> Or maybe I'm missing something...
>
> On Sat, Oct 31, 2020, at 20:27, Abdelatif Guettouche wrote:
> > It's nice to revive this discussion.
> >
> > As I was saying in Github, I don't see a "not too awkward" way to
> > include the Kconfig file directly and use it as any Kconfig we have.
> >
> > 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.
> >
> > On Sat, Oct 31, 2020 at 4:38 PM Alan Carvalho de Assis
> > <ac...@gmail.com> wrote:
> > >
> > > Hi Everyone,
> > >
> > > The move to the Kconfig is finally happening and we would have the
> > > chance to make suggestions.
> > >
> > > Please take a look in the discussion here:
> > >
> > > https://github.com/lvgl/lvgl/pull/1875
> > >
> > > Thank you Abdelatif for let me know about it, I didn't see the github
> > > notification.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On 8/25/20, Alan Carvalho de Assis <ac...@gmail.com> wrote:
> > > > Hi Everyone,
> > > >
> > > > Mr. Gábor Kiss-Vámosi contacted and told me that LVGL is moving to
> use
> > > > Kconfig:
> > > >
> > > > "At LVGL we are planning to add a Kconfig file to the main repo but
> we
> > > > are not sure if it will harm the existing Kconfig based projects.
> > > >
> > > > Could you comment on what your requirements are and what we should
> > > > consider in order to allow NuttX to use LVGL's Kcofig file or - if
> > > > it's not possible - to make sure it won't bother your Kconfig file?"
> > > >
> > > > So, I think this is a good opportunity to make NuttX more integrated
> > > > with LVGL. Suggestions are welcome.
> > > >
> > > > Gábor, I added you CC here because I don't know if you are subscribed
> > > > to NuttX at Apache Foundation mailing list.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> >
>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
whoa, I did so many mistakes (it happens everything I don't sleep well)
Let's see it:
On 11/2/20, Alan Carvalho de Assis <ac...@gmail.com> wrote:
> Hi Gábor,
>
> On 11/2/20, Gábor Kiss-Vámosi <ki...@gmail.com> wrote:
> sic
>>
>> Why is it not an issue with other projects you use in NuttX? Have we
>> missed
>> something?
>>
>
This is the first time we need to integrate with an external library
that uses Kconfig and have more configuration options. All other
libraries/applications are mostly fixed and they don't evolve over the
time.
It should be nice if kconfig-frontend was more dynamic: we could
to select the option: [x] Enable LVGL and then it show up a download
progress bar screen and after the tarball is decompressed it displays
the LVGL Kconfig.
But for today, let's just get your Kconfig and put it at
apps/graphics/lvgl/ it should be enough. And we just need to do it a
time when a new LVGL version is released.
BR,
Alan
>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Gábor,
On 11/2/20, Gábor Kiss-Vámosi <ki...@gmail.com> wrote:
sic
>
> Why is it not an issue with other projects you use in NuttX? Have we missed
> something?
>
This is the first time we need to integrate with an external library
that uses Kconfig and have more configuration options. All other
libraryies/applications are most fixed and they don't evolve other the
time.
It should be nice if kconfig-frontend was more dynamic: we could
select the option: [x] Enable LVGL and then it show up a download
progress bar screen and after the tarball is decompressed it display
the LVGL Kconfig.
But for today, let's just get your Kconfig and put it at
apps/graphics/lvgl/ it should be enough. And we just need to do it a
time when a new LVGL version is released.
BR,
Alan
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by Gábor Kiss-Vámosi <ki...@gmail.com>.
Sure, thank you too for your support! :)
Regards,
Gabor
Matias N. <ma...@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. <ma...@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. <ma...@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. <ma...@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
>
>
>
>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by "Matias N." <ma...@imap.cc>.
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. <ma...@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. <ma...@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. <ma...@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
>>>>
>>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by Gábor Kiss-Vámosi <ki...@gmail.com>.
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. <ma...@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. <ma...@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. <ma...@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
>
>
>
>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by "Matias N." <ma...@imap.cc>.
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. <ma...@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. <ma...@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
>>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by Gábor Kiss-Vámosi <ki...@gmail.com>.
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. <ma...@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. <ma...@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
>
>
>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by "Matias N." <ma...@imap.cc>.
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. <ma...@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
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by Gábor Kiss-Vámosi <ki...@gmail.com>.
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. <ma...@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
>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by "Matias N." <ma...@imap.cc>.
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
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Matias,
The idea of using the Kconfig supplied by LVGL is to simplify our
building process, but of course, it needs to avoid some drawbacks that
can appear during this development.
Currently we already ship our own Kconfig
(apps/graphics/lvgl/Kconfig), but since LVGL is moving to Kconfig we
need to get this opportunity to simplify things.
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. :-)
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?
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.
BR,
Alan
On 11/1/20, Matias N. <ma...@imap.cc> wrote:
> I'd really hate to have to go through a separate configuration process. I
> would think that we are losing functionality instead of gaining something in
> that case. Also, if I understand correctly this would mean that we have one
> extra config file to handle besides NuttX's one, and we have to keep them in
> sync and store them together everywhere.
>
> If this is all due to the Kconfig file (or files) being stored inside the
> sources, couldn't we just ship the official Kconfig files ourselves? It
> would mean that we maintain a specific version of LVGL and whenever we
> upgrade it we download new Kconfig files into the directory (licensing could
> be an issue, but maybe this can be discussed?). The source tarball would be
> downloaded as usual, this would just mean we pre-download (and store) the
> Kconfig files. Maybe LVGL can even offer a separate tarball for Kconfig
> files to avoid having to manually extract them from the main tarball.
>
> Let's try to find a way we can make it work reasonably instead of making
> this unnecessarily complex.
>
> Best,
> Matias
>
> PS: I think we lost Gabor from the CC list, I'm re adding him. Remember to
> reply with "reply to all" (I think I was the one who messed up anyway).
>
> On Sun, Nov 1, 2020, at 13:18, Brennan Ashton wrote:
>> On Sun, Nov 1, 2020, 2:24 AM Abdelatif Guettouche <
>> abdelatif.guettouche@gmail.com> wrote:
>>
>> > > I'm confused how this would work. Don't you need to download the
>> > > source
>> > > tarball which is controlled via kconfig before you could source it?
>> >
>> > This is the part I'm calling "awkward", we can provide a dummy Kconfig
>> > that we override when we download the tarall (during context target).
>> > However we will not have the LVGL Kconfig options until that happens.
>> > (which is precisely the awkward part.)
>> >
>> > > It you want to change settings you would do
>> > > make lvgl-menuconfig
>> > > make lvgl-savedefconfig
>> >
>> > Who will provide these targets?
>> >
>>
>> We would provide them. They would also trigger downloading and
>> exactracting
>> the tarball. Then we would be calling make menuconfig etc... against the
>> LVGL project.
>>
>> For an example of what I am talking about see section 7 here
>> https://buildroot.org/downloads/manual/manual.html#_configuration_of_other_components
>>
>> And also section 9.1 for how the defconfigs are stored for these
>> components.
>>
>> --Brennan
>>
>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by "Matias N." <ma...@imap.cc>.
I'd really hate to have to go through a separate configuration process. I would think that we are losing functionality instead of gaining something in that case. Also, if I understand correctly this would mean that we have one extra config file to handle besides NuttX's one, and we have to keep them in sync and store them together everywhere.
If this is all due to the Kconfig file (or files) being stored inside the sources, couldn't we just ship the official Kconfig files ourselves? It would mean that we maintain a specific version of LVGL and whenever we upgrade it we download new Kconfig files into the directory (licensing could be an issue, but maybe this can be discussed?). The source tarball would be downloaded as usual, this would just mean we pre-download (and store) the Kconfig files. Maybe LVGL can even offer a separate tarball for Kconfig files to avoid having to manually extract them from the main tarball.
Let's try to find a way we can make it work reasonably instead of making this unnecessarily complex.
Best,
Matias
PS: I think we lost Gabor from the CC list, I'm re adding him. Remember to reply with "reply to all" (I think I was the one who messed up anyway).
On Sun, Nov 1, 2020, at 13:18, Brennan Ashton wrote:
> On Sun, Nov 1, 2020, 2:24 AM Abdelatif Guettouche <
> abdelatif.guettouche@gmail.com> wrote:
>
> > > I'm confused how this would work. Don't you need to download the source
> > > tarball which is controlled via kconfig before you could source it?
> >
> > This is the part I'm calling "awkward", we can provide a dummy Kconfig
> > that we override when we download the tarall (during context target).
> > However we will not have the LVGL Kconfig options until that happens.
> > (which is precisely the awkward part.)
> >
> > > It you want to change settings you would do
> > > make lvgl-menuconfig
> > > make lvgl-savedefconfig
> >
> > Who will provide these targets?
> >
>
> We would provide them. They would also trigger downloading and exactracting
> the tarball. Then we would be calling make menuconfig etc... against the
> LVGL project.
>
> For an example of what I am talking about see section 7 here
> https://buildroot.org/downloads/manual/manual.html#_configuration_of_other_components
>
> And also section 9.1 for how the defconfigs are stored for these components.
>
> --Brennan
>
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Sun, Nov 1, 2020, 2:24 AM Abdelatif Guettouche <
abdelatif.guettouche@gmail.com> wrote:
> > I'm confused how this would work. Don't you need to download the source
> > tarball which is controlled via kconfig before you could source it?
>
> This is the part I'm calling "awkward", we can provide a dummy Kconfig
> that we override when we download the tarall (during context target).
> However we will not have the LVGL Kconfig options until that happens.
> (which is precisely the awkward part.)
>
> > It you want to change settings you would do
> > make lvgl-menuconfig
> > make lvgl-savedefconfig
>
> Who will provide these targets?
>
We would provide them. They would also trigger downloading and exactracting
the tarball. Then we would be calling make menuconfig etc... against the
LVGL project.
For an example of what I am talking about see section 7 here
https://buildroot.org/downloads/manual/manual.html#_configuration_of_other_components
And also section 9.1 for how the defconfigs are stored for these components.
--Brennan
Re: LVGL moving to Kconfig, how we could integrated better with them
Posted by Abdelatif Guettouche <ab...@gmail.com>.
> I'm confused how this would work. Don't you need to download the source
> tarball which is controlled via kconfig before you could source it?
This is the part I'm calling "awkward", we can provide a dummy Kconfig
that we override when we download the tarall (during context target).
However we will not have the LVGL Kconfig options until that happens.
(which is precisely the awkward part.)
> It you want to change settings you would do
> make lvgl-menuconfig
> make lvgl-savedefconfig
Who will provide these targets?
On Sun, Nov 1, 2020 at 1:04 AM Brennan Ashton <ba...@brennanashton.com> wrote:
>
> I'm confused how this would work. Don't you need to download the source
> tarball which is controlled via kconfig before you could source it?
>
> Every other system I have used that does this has you supply the defconfig
> to the top level build system. It you want to change settings you would do
> make lvgl-menuconfig
> make lvgl-savedefconfig
> And the save the updated defconfig.
>
> So you might have
> boards/sim/sim/config/LVGL/defconfig
> boards/sim/sim/config/LVGL/lvgldefconfig
>
> The NuttX config would contain
> LVGL_DEFCONFIG="boards/sim/sim/config/LVGL/lvgldefconfig"
>
> This is how you handle the Linux kernel or uboot in Buildroot.
>
> On Sat, Oct 31, 2020, 4:24 PM Matias N. <ma...@imap.cc> wrote:
>
> > But isn't the point that we would just source their Kconfig?
> > What I mentioned previously is that maybe it can be done so that
> > they can accept an external header providing the Kconfig defitions
> > (in our case nuttx/config.h).
> >
> > Or maybe I'm missing something...
> >
> > On Sat, Oct 31, 2020, at 20:27, Abdelatif Guettouche wrote:
> > > It's nice to revive this discussion.
> > >
> > > As I was saying in Github, I don't see a "not too awkward" way to
> > > include the Kconfig file directly and use it as any Kconfig we have.
> > >
> > > 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.
> > >
> > > On Sat, Oct 31, 2020 at 4:38 PM Alan Carvalho de Assis
> > > <ac...@gmail.com> wrote:
> > > >
> > > > Hi Everyone,
> > > >
> > > > The move to the Kconfig is finally happening and we would have the
> > > > chance to make suggestions.
> > > >
> > > > Please take a look in the discussion here:
> > > >
> > > > https://github.com/lvgl/lvgl/pull/1875
> > > >
> > > > Thank you Abdelatif for let me know about it, I didn't see the github
> > > > notification.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On 8/25/20, Alan Carvalho de Assis <ac...@gmail.com> wrote:
> > > > > Hi Everyone,
> > > > >
> > > > > Mr. Gábor Kiss-Vámosi contacted and told me that LVGL is moving to
> > use
> > > > > Kconfig:
> > > > >
> > > > > "At LVGL we are planning to add a Kconfig file to the main repo but
> > we
> > > > > are not sure if it will harm the existing Kconfig based projects.
> > > > >
> > > > > Could you comment on what your requirements are and what we should
> > > > > consider in order to allow NuttX to use LVGL's Kcofig file or - if
> > > > > it's not possible - to make sure it won't bother your Kconfig file?"
> > > > >
> > > > > So, I think this is a good opportunity to make NuttX more integrated
> > > > > with LVGL. Suggestions are welcome.
> > > > >
> > > > > Gábor, I added you CC here because I don't know if you are subscribed
> > > > > to NuttX at Apache Foundation mailing list.
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > >
> >