On 5 February 2014 11:52, Colin Walters <walt...@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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
