GNOME Bugzilla – Bug 784351
Create separate libdevhelp git repository
Last modified: 2021-05-17 15:50:10 UTC
Proposal: create a separate libdevhelp git repository. There are several problems with the Devhelp library in its current shape: 1. API stability is not really guaranteed, even if we try to not break Anjuta and gnome-builder. 2. When we'll switch to GTK+ 4, all applications depending on the Devhelp library would need to be ported to GTK+ 4 during the same development cycle. This is clearly not practical. So I propose to: - Fork the devhelp repo into libdevhelp where only the library part is kept. - The Devhelp app would depend on the latest version of libdevhelp. - API stability would be guaranteed in libdevhelp; if we want to break the API, we simply bump the major version, making it parallel-installable with previous major versions (like GTK+ 3 and GTK+ 4). - When we port libdevhelp to GTK+ 4, we bump the major version so that the GTK+ 3 version is still available. I don't plan to do this right away, but I think this needs to be done at least before porting to GTK+ 4.
*** Bug 509338 has been marked as a duplicate of this bug. ***
(In reply to Sébastien Wilmet from comment #0) > Proposal: create a separate libdevhelp git repository. > > There are several problems with the Devhelp library in its current shape: > 1. API stability is not really guaranteed, even if we try to not break > Anjuta and gnome-builder. > 2. When we'll switch to GTK+ 4, all applications depending on the Devhelp > library would need to be ported to GTK+ 4 during the same development cycle. > This is clearly not practical. > > So I propose to: > - Fork the devhelp repo into libdevhelp where only the library part is kept. > - The Devhelp app would depend on the latest version of libdevhelp. > - API stability would be guaranteed in libdevhelp; if we want to break the > API, we simply bump the major version, making it parallel-installable with > previous major versions (like GTK+ 3 and GTK+ 4). > - When we port libdevhelp to GTK+ 4, we bump the major version so that the > GTK+ 3 version is still available. > > I don't plan to do this right away, but I think this needs to be done at > least before porting to GTK+ 4. +1 from me, for what it's worth
Before forking the repo, the build system should be ported to Meson first, because it would be stupid to do it two times. See bug #783819. I think we won't keep the Autotools ad vitam aeternam, longer term keeping the Autotools will be problematic because of missing macros.
(In reply to Sébastien Wilmet from comment #3) > Before forking the repo, the build system should be ported to Meson first, > because it would be stupid to do it two times. See bug #783819. I've changed my mind, porting to Meson can be done later. If there is only the library *or* the app to port to Meson, the port is easier and thus has better chances to replace Autotools sooner (at least in one of the two modules). If the Meson port is done after the module split, I don't think there will be a lot of work duplication, since the things to port are different.
In the wip/devhelp-next branch I've split the source files to separate the lib from the app. The lib is in devhelp/ and the app is still in src/. In src/ the goal is to #include <devhelp/devhelp.h> only to access the lib. There is one remaining problem if the libdevhelp git repo is created: the lib uses GSettings (with DhSettings, DhSettings is currently part of the lib) in DhBookManager for the list of disabled books. And the app #include "devhelp/dh-settings.h" (that header is not installed, it is not a public header). I think the solution is to replace the use of GSettings in the lib by a property, and bind the property to GSettings in the app. Because what if two different major versions of libdevhelp are installed and both use GSettings? If the lib provides GSettings, it needs to be parallel-installable, so there would be GSettings for libdevhelp 3 and GSettings for libdevhelp 4, but it would not be convenient for a user to loose all his/her settings each time there is a new major version of libdevhelp. So there should be only one set of GSettings for Devhelp, so the obvious place to provide them is in the app, not the lib. Or if the lib wants to use GSettings (to provide a higher-level API), the path to the GSettings need to be provided at run-time (and the lib can introspect the GSettings to see if all it needs are there with the good types).
Another thing to not forget, probably for libdevhelp 4, is to add: #error "Only <devhelp/devhelp.h> can be included directly."
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/devhelp/-/issues/43.