Re: libgsystem as a shared library

[Richard Hughes <hughsient gmail com>]

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.