New: LVGL - Light and Versatile Graphics Library build_tarballs.jl

[notinaboat]

LVGL - Light and Versatile Graphics Library
https://github.com/lvgl/lvgl

[imciner2]

This is a very odd list of platforms. Why does it only build on these two specific ones?

[notinaboat]

These are the only two platforms that I am able to test (my dev laptop and my embedded target board).

[fingolfin]

That's not a great reason to limit the list: it's not expected that you personally test all platforms. But by opening up, you vastly expand who can benefit from this JLL; and if anyone uses them, and there are problems, then they may give you feedback or may even help out.

Of course if other platforms cause build errors that are hard to track down, it's OK to remove them and worry about those you need first. But looking at this list I'd be surprised if not at least Linux x86 and mac ARM would work, too.

So how about starting with the full list, and see if any build jobs fail here on Yggdrasil, and then we can see how to proceed :-)

[imciner2]

This patch has a lot of changes, and they aren't documented. Why is this patch needed here in Yggdrasil, and will you send it upstream so we don't have to try keeping it updated when a new version is introduced?

[notinaboat]

That's a fair question. I probably should have split the patch up to make the purpose of the different parts more obvious.

Here is a summary:

CMakeLists.txt and custom.cmake -- This is cmake configuration to build LVGL as shared libraries and using the SDL2 backend (based on the example here).

lv_conf_template.h -- This is build configuration to enable SDL2 integration (based on the example here)

lv_font.[ch] -- This is an access function to allow access to const struct font definitions. As far as I know, Libdl does not provide a way to access a const struct defined in a dynamic library (dlsym only returns function pointers). This access function is probably not interesting to the upstream project. I assume they are focused on supporting users who are accessing the library from C.

[fingolfin]

Yeah ideally each of those should be a separate patch. Bonus points if they use the "git commit patch format" (such as here) which includes spaces for a "commit message" that can contain explanations such as yours above.

My experience is that you yourself will greatly benefit from this when you try to update this recipe in the future :-).

[imciner2]

Has this been sent upstream? I would guess we aren't the only ones seeing this issue.

[notinaboat]

I doubt anyone else would be using the very old (2016) version of the MacOS system headers that are used by BinaryBuilder.jl
So, this isn't suitable to send upstream. It's just a hack to build using Yggdrasil's outdated cross compiler setup.

[fingolfin]

Why is this using a git snapshot and not a released version? In particular it seems the latest released version is 9.2.0, so why do you call this snapshot "9.3.0" ?

[giordano]

It's fine to use a git source, they don't seem to offer stable release tarballs as far as I could see. But the question about the version number still stands.

[fingolfin]

It's true they don't offer stable release tarballs, just the the autogenerated ones (my guess would be that as usual they are not even aware that those archives are not stable). But they still have release tags, so one could use e.g. the commit for 9.2.0 to packages that...

And by the discussion in lvgl/lvgl#7098 and lvgl/lvgl#6763 it seems 9.3.0 is only planned for early 2025, so it seems unlikely to match what is being used here as 9.3.0

[kisvegabor]

Hey,

I've just saw in this LVGL issue that your integrating LVGL into Julia. It's very exciting and I'd love to

• hear more about the motivation/use cases
• hear any technical questions/issues
• spread the word of this integration