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. <mat...@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.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 >> >
