Re: libgsystem as a shared library
- From: Colin Walters <walters verbum org>
- To: desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: libgsystem as a shared library
- Date: Wed, 05 Feb 2014 15:16:28 +0000
On Wed, Feb 5, 2014 at 8:48 AM, Richard Hughes <hughsient gmail com> wrote:
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.
That's a good point. Perhaps there's a simple solution - I just never
break API/ABI. That would come at the cost of a potentially uglier API for
libgsystem (gs_console_open2() or something) but with the end game in
mind of landing in GLib with a nicer API after we've learned from real world
experience, that's a fine cost to pay.
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.
Unfortunately I personally don't have the luxury for many of my
projects of being tightly coupled to the GNOME release cycle.
For gobject-introspection, gjs, and hotssh? Sure. For ostree and NetworkManager,
I need to be able to run on older systems.
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.
You may be right; perhaps I was initially too rigid in saying they couldn't
go in GLib because of MSVC/Sun Studio.
But you know...Oracle *can* use gcc, and people can cross build from GNU/Linux
for win32 instead of using MSVC.
Maybe it's fine to just allow app authors to opt in and #include <glib/localalloc.h> or
<gio/localalloc.h>.
I filed a GLib bug, we can discuss there:
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]