Rethink ABI practices

[vaxerski]

Our ABI usage mostly relies on two things:

• hopes and prayers
• using the heap

Reason being we bump ABI when the layout changes, not the size (e.g. appending to a class)

Solutions:

• wrap internal data structures in a struct passed to a unique_ptr
• only expose public data and every object has to be created by the lib, making it a subclass
• mark an ABI break every time a class is expanded

ref hyprwm/hyprpaper#225 #23 hyprwm/Hyprland#8813 hyprwm/Hyprland#8797

cc @fufexan @outfoxxed @gulafaran

(this also applies to all other hypr* libs)

[vaxerski]

in the meantime, I'll make a breaking update to HU to nicely tell packagers to rebuild.

[outfoxxed]

I don't think ABI actually matters that much for now. We have tools such as hyprpm and nix that handle it, and the expectation that abi will break on every update.

Personally I think the lack of a stable API is far more of an actual issue, though I am aware that isn't going to become stable.

[vaxerski]

this is not about hyprpm xd

[outfoxxed]

Mb, misread

I'm not a fan of PIMPL, though it is a potential solution. I think its better suited to projects actually attempting to keep a stable API and ABI, and the subclass thing sounds confusing and probably annoying to work with.

That leaves marking an ABI break, which seems fine to me, because the ABI is breaking.

[cpiber]

That leaves marking an ABI break, which seems fine to me, because the ABI is breaking.

As a maintainer of a package, I would prefer a stable ABI. Breaking the ABI requires a rebuild for everything depending on that package. There's 12 other projects from hypr that depend on hyprutils, which I all had to rebuild today to make sure they use the correct library

[outfoxxed]

That leaves marking an ABI break, which seems fine to me, because the ABI is breaking.

As a maintainer of a package, I would prefer a stable ABI. Breaking the ABI requires a rebuild for everything depending on that package. There's 12 other projects from hypr that depend on hyprutils, which I all had to rebuild today to make sure they use the correct library

There isn't automated tooling for this?

[cpiber]

That leaves marking an ABI break, which seems fine to me, because the ABI is breaking.

As a maintainer of a package, I would prefer a stable ABI. Breaking the ABI requires a rebuild for everything depending on that package. There's 12 other projects from hypr that depend on hyprutils, which I all had to rebuild today to make sure they use the correct library

There isn't automated tooling for this?

The CI (launchpad.net) performs the build and publishes the package, but I had to trigger the rebuild, there is no automated process for that to my knowledge, at least for Ubuntu/Debian

[vaxerski]

"don't break the ABI" is easier said than done, especially since our software is not designed with a stable ABI in mind as the top priority, but more like ease of development.

As a package maintainer, you will have to deal with this one way or another. Perhaps you should consider making a quick task to rebuild all dependents of a package?

[cpiber]

I'm not saying to completely avoid it, what you did is fine to me. I have set up some scripts.

and the expectation that abi will break on every update.

I just wanted to mention that breaking for no reason is going to be annoying quickly