Re: libgsystem as a shared library
- From: Richard Hughes <hughsient gmail com>
- To: Colin Walters <walters verbum org>
- Cc: desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: libgsystem as a shared library
- Date: Wed, 5 Feb 2014 13:48:11 +0000
On 5 February 2014 11:52, Colin Walters <walters verbum org> wrote:
GSConsole
gsystem-log.h (systemd journal via a GLib-like API, also acts as a "soft"
dependency)
Yes, that sounds awesome, but if libgsystem is going to be an "egg"
replacement I would say it's better to just copy and paste the source
files into modules; having an external library indicates some kind of
API and ABI promises, and you don't want to be proxying stuff in glib
for the next decade.
Second, it contains "backported" API. An example of this is "GSSubprocess",
which is now in GLib. But a lot of my code (and NetworkManager) has to run
on EL7 for example, which is just GLib 2.36. So it makes sense to have a
"common backport" area.
As a shared library I'm not sure this argument holds, as a git
submodule it makes a lot of sense. I think putting stuff like this in
glib and surrounding them with I_KNOW_THIS_API_IS_UNSTABLE guards for
an unstable cycle makes a lot of sense while the API is still being
worked on and the early adopters are willing to release tarballs at a
moments notice.
Third, it will contain APIs like the local allocation macros that I don't
think should go into GLib. (Although this is admittedly debatable)
I think they would be awesome in glib itself, and certainly would
encourage developers to start using them.
Richard.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]