Re: libgsystem as a shared library



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:
https://bugzilla.gnome.org/show_bug.cgi?id=723686



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]