On Wed, Feb 5, 2014 at 8:48 AM, Richard Hughes <[email protected]>
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
_______________________________________________
desktop-devel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
