Use lagom from system libraries?

[vpzomtrrfrt]

It looks like lagom is already being dynamically linked, so what would it take to build ladybird with a globally installed copy of lagom instead of requiring the serenity source directly?

[thesamesam]

Yeah, this would be a big help when packaging. Thanks in advance for your consideration!

[ADKaster]

That would require CMake changes to find_package(Lagom) before trying to FetchContent.

Given how quickly Lagom libraries change though, I'm not sure how valuable that would be. There's absolutely no promise of a stable ABI for those libraries.

[diegoiast]

Lagom has no stable API. If you package lagom and ladybird in different packages - both need to be on the same git commit - otherwise, the loader will not even load the main elf.

You need to think of lagom as private API or ladybird.

[xyproto]

When I packaged netsurf for Arch, I made the dependencies versioned. A similar approach could maybe work for ladybird and lagom.

[ADKaster]

Perhaps, but there are no versions of Lagom or Ladybird at the moment, only trunk. As a developer focused project, serenity does not have versions. See the rationale here #2 (comment)

[xyproto]

Dates like 20220912 can double as version numbers, like for ladybird or plan9port.

[thesamesam]

Lagom has no stable API. If you package lagom and ladybird in different packages - both need to be on the same git commit - otherwise, the loader will not even load the main elf.

You need to think of lagom as private API or ladybird.

I understand this and we can cope fine with unstable ABI in Gentoo. There's two issues though:

1. As it is, it's awkward to then share /usr/share/serenity between packages;
2. It makes it harder to build without network access.

[ADKaster]

I created #62 that adds some CMake install rules that more or less encode the "Lagom libraries are private impl libraries of serenity" concept in code.

I personally think there's some serious refactoring needed to the Lagom CMakeLists in the serenity repository before it will be less awkward to share the libraries between several packages, but maybe it's less work than I think to get something workable for the more unstable distros.

The main issue being, for cross-compiling like for the Andrioid port I made the fact we have Host libraries and target libraries that end up having the same imported name caused me to change the target_link_libraries for ladybird to reference the "build time' names of the Lagom libraries, rather than Lagom:: namespace prefixed ones. A find_package() solution would run into those issues, which originate from hacks in the Lagom build itself.