On Tue, 9 Feb 2016 01:11:48 +0100 Benoit Gschwind <[email protected]> wrote:
> Hello, > > while I developing the option 2. I raise few questions because this > option explicit the fact that back-ends does not share the same API (at > less for the configuration). To resolve the issue I found the following > options: > > 1. find a common configuration API (use key/value) > > 2. have the following split: > - libweston: every thing that is not in back-ends. > - libbackendx, libbackendy, ... : back end implementation of > configuration stuff, that you must link with libweston (this is the > uncommon API parts of back-ends > - backendx.so, backendy.so, ... : the loadable (common API) part of > backends. > > 3. have the following split: > - libweston: every thing that is not in backends. > - libbackendx, libbackendy, ... : back end are not more loadable, and > are linked at build, developer can drop useless back-ends. Hi, I understand option 2, but I do not understand how option 3 could work. I suppose option 3 means that a compositor would be built to run just a single backend, and you cannot choose it at runtime? We certainly do not want to pose that kind of a limitation. We also do not want to load more than one backend at a time to the compositor process, because different backends pull in different libraries and sometimes those are a significant burden. It would be sad if a compositor that supported both DRM and X11 backends would *always* load libX11 regardless of which it is using. It would be useless work at start-up, and also make the dependencies of the compositor too much: you cannot choose to install it with libs for DRM only. That would be awkward for distributions. About distributions, you can see the explanation on how Weston project will be intended to be split into binary packages in a distribution in Weston's readme. > Maybe you have better idea, from my point of view I will prefer the > third one. it's not optimal in term of loading and memory because we > need to load all available back-ends but it's cleaner. For the above reasons, I believe option 3 is not acceptable. > Maybe in the option 3 we can hide the option 2 inside, that load a > backend.so only once it's used to save memory and loading time. > > This is something I didn't foresee in my previous e-mail. Right, so you propose we add yet another bunch of libraries, one per backend, to be linked to by the compositor program at build time. The benefit is that libweston.so would not export any backend-specific symbols. I think that is the only benefit, and the amount of code inside these libraries would be quite small. Therefore to me the trade-off compared to libweston.so just exporting those symbols itself is not worth it. The summary in your previous email on the possible design choises is still accurate in my opinion, this new idea here is just bringing more complexity that it is worth. Thanks, pq
pgpy0Ropzh0oG.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
