On Mon, 07 Oct 2019 14:16:32 -0400 "Keith Packard" keithp@keithp.com wrote:
Daniel Stone daniel@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, etc.
Hi,
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.
Thanks, pq