liboutput: thoughts about shared library on top of DRM/KMS
ppaalanen at gmail.com
Tue Oct 8 07:15:28 UTC 2019
On Mon, 07 Oct 2019 14:16:32 -0400
"Keith Packard" <keithp at keithp.com> wrote:
> Daniel Stone <daniel at fooishbar.org> writes:
> > I think there would be a load of value in starting with simple helpers
> > which can be used independently of any larger scheme, tackling that
> > list above.
> Yeah, a helper library that didn't enforce at tonne of policy and just
> let the user glue things together on their own is probably going to be
> more generally usable by existing and new systems.
> I definitely like the idea of stealing the best parts of all existing
> systems and trying to make them work together.
> How many libraries we end up with isn't nearly as important to me as
> making sure they work well together; common data types, similar style,
a bunch of helpers is the more attractive idea to me too. We just have
to pay attention to API/ABI instability vs. usage: we should be able to
both redesign the API at will to go forward, but people will not be
happy using a library that breaks ABI all the time.
Libweston worked around that issue by making all major release versions
parallel-installable. That means literally all files or directories
have the major number in their base name. Another option would be to
have a static library only. I'm not sure which one would be more
attractive. If going with static-library-only, then we probably one day
want to convert into a dynamic library, and then the question of
whether the ABI is stable enough will arise again.
Using Meson should make the static-lib-only approach very easy,
downstream projects could include liboutput as a git sub-module or
such. That should eliminate the version dependency issues that builds
might otherwise have.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the dri-devel