cederom commented on issue #13825: URL: https://github.com/apache/nuttx/issues/13825#issuecomment-2424863527
TLDR: Its a nice idea to support several LVGL versions in NuttX, but its out of scope of this PR where we want to have specifically 9.2.1 in 12.7.0, we should talk about that in a separate Issue not to mix too many things in one place? > > @TimJTi: Is it feasible/possible to allow a choice of LVGL version via Kconfig? > > I know there is a copy/paste of the LVGL Kconfig content to the NuttX one which is a fudge, but I am not experienced enough with Kconfig syntax to know if the archive file path can be constructed from the user choice so the correct file will be downloaded? > > I've seen an argument here that we don't want to have to have a 2 stage process (select LVGL, then execute a make to get the archive loaded and only then are the correct Kconfig settings available) but surely there's a way around this? > > I'm not working today but I will try and research this as a possibility over the weekend. > > @TimJTi: I tracked down the original discussion thread from the mail archive [here](https://www.mail-archive.com/[email protected]/msg04775.html) and had a look around for clever "tricks". Sadly I have to conclude that we have little choice but to do the copy/paste of LVGL's Kconfig contents when there's an LVGL upgrade: Thanks @TimJTi :-) Another approach would be to keep different LVGL releases in separate directories and reference them with a different configurations? Then process them with Make/CMake just as we do with external packages that are then patched before use in NuttX? > 1. Kconfig doesn't execute any "code" as such so it can't go and grab the required LVGL Kconfig file on the fly. This may be a good design goal. This tool is only for configuration. Make/CMake is for processing the configuration. > 2. I couldn't see a way for kconfig to reference a URL By assigning a configuration string variable as URL or directory location holding specific LVGL version? > 3. Even if it could, it would need an internet connection which I gather should not be a "requirement" for this to allow offline working (does anyone these days LOL) > > 4. kconfiglib might give more options as it could execute python code (not anything I have experience of) if I understand it right. But that's not what we use. Again its not Kconfig task to perform operations, its only for configuration :-) > 5. Even if we "revert" and allow the version of LVGL to be used (as it used to be) it falls over for most of the above reasons. This may be treated as "just onother different configuration"? > 6. LVGL "Master" doesn't ever exist as a downloadable archive/tarball so we can't even offer that...and most of the above applies too! I think it does, look: * Official release: https://github.com/lvgl/lvgl/archive/refs/tags/v9.2.0.tar.gz * Release branch archive: https://github.com/lvgl/lvgl/archive/refs/heads/release/v9.2.zip * Master package: https://github.com/lvgl/lvgl/archive/refs/heads/master.tar.gz We should stick to releases in the first place. Now its a "special" situation where we want to test stuff right before a release so we use release branch package, but we will switch this variable to a release package again as soon as it shows up. But having a dedicated lvgl git master port may be good for testing, it should be possible to use lvgl master too, and you may call this port "lvgl-devel" to align with other OS nomenclature :-) > Guess we will stick withe what we've got - but I will do a small documentation PR to add a "how to" to explain how to use a different LVGL version by cloning the LVGL repo directly into your own nuttx-apps space and copy/pasting the LVCGL Kconfig to NuttX's local copy. Some better process is required here. You may take a look at FreeBSD ports how things are done [1] as an example the process is similar in NuttX. There are various "ports" where the same program/library may exist in different versions (mutually exclusive, i.e. mysql, python, qt, etc). We may have different LVGL applications / system libraries here too for different LVGL versions. Also note the standard steps like "fetch" as the first step where connections are possible, then "extract", "patch", "configure", "build", "stage" (move binaries from src package to dedicated OS layout compliant prefix), "package" (create system package out of stage location), "install" - all this makes process clean and repeatable for all ports. [1] https://docs.freebsd.org/en/books/porters-handbook/slow-porting -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
