After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784351 - Create separate libdevhelp git repository
Create separate libdevhelp git repository
Status: RESOLVED OBSOLETE
Product: devhelp
Classification: Applications
Component: General
unspecified
Other All
: Normal enhancement
: ---
Assigned To: devhelp-maint
devhelp-maint
: 509338 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-06-29 15:49 UTC by Sébastien Wilmet
Modified: 2021-05-17 15:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sébastien Wilmet 2017-06-29 15:49:42 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.
Comment 1 Sébastien Wilmet 2017-06-29 15:54:35 UTC
*** Bug 509338 has been marked as a duplicate of this bug. ***
Comment 2 Aleksander Morgado 2017-06-30 09:09:48 UTC
(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
Comment 3 Sébastien Wilmet 2017-08-10 10:48:13 UTC
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.
Comment 4 Sébastien Wilmet 2018-02-23 11:26:16 UTC
(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.
Comment 5 Sébastien Wilmet 2018-02-23 11:47:55 UTC
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).
Comment 6 Sébastien Wilmet 2018-02-23 11:54:58 UTC
Another thing to not forget, probably for libdevhelp 4, is to add:

#error "Only <devhelp/devhelp.h> can be included directly."
Comment 7 GNOME Infrastructure Team 2021-05-17 15:50:10 UTC
-- 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.