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? 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 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. 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 > > > 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 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
On Sun, Nov 1, 2020, 2:24 AM Abdelatif Guettouche < abdelatif.guettou...@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
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.guettou...@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
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. 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.guettou...@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
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
