GNOME Bugzilla – Bug 723686
provide local allocation macros
Last modified: 2015-04-09 03:19:54 UTC
We should consider providing predefined local allocation macros for key GLib types (GPtrArray, etc.), as well as GObject, and potentially the custom boxed types in Gio. #include <glib/localalloc.h> #include <gobject/localalloc.h> #include <gio/localalloc.h> See: https://wiki.gnome.org/Projects/LibGSystem There's been some uptake of it lately, e.g.: https://git.gnome.org/browse/gnome-terminal/commit/?id=e9cab814892fc5b697e7574a827ac4d5e16f2b3b This would help reduce the need for various projects to link to libgsystem. It would have to be documented well that by including this, projects will not be compilable via MSVC/Sun Studio. Any thoughts/objections/praise?
My big concern about this, summed up in an example: dconf doesn't work on Windows and it doesn't ever make sense to have it there. I may as well use these macros, right? They'd make my life a lot easier... But now dconf doesn't work on suncc, xlc, or any other POSIX-complying compiler that's not GCC or clang. Of course it's my choice as a maintainer to decide if I want to do this or not... but I'm not totally convinced that this is a decision that we should actively push people toward.
(In reply to comment #1) > Of course it's my choice as a maintainer to decide if I want to do this or > not... but I'm not totally convinced that this is a decision that we should > actively push people toward. First note that if we choose to do this, I would carefully engineer the build of glib itself so that we couldn't accidentally include the header; basically inject a #define into config.h that causes an error if it's defined when the localalloc header is included. As far as "actively pushing", well I did do some "pushing" initially, but it's been a fairly organic process after that. I didn't point chpe at it, he chose to include them for gnome-terminal. Would having them in glib encourage people more? Most likely. Would it also encourage the Sun Studio maintainers to support it? Also likely =) So...this is not a "must decide now" bug, but let's keep it open and have a discussion. In the meantime I'm working on making libgsystem a shared library.
(In reply to comment #2) > Would having them in glib encourage people more? Most likely. Would it also > encourage the Sun Studio maintainers to support it? Also likely =) This is a very interesting point that I didn't consider... > In the meantime I'm working on making libgsystem a shared library. That's good to hear -- it seems to have grown beyond its status as a copy-paste lib a while ago...
(In reply to comment #3) > (In reply to comment #2) > > Would having them in glib encourage people more? Most likely. Would it also > > encourage the Sun Studio maintainers to support it? Also likely =) > > This is a very interesting point that I didn't consider... on that note, it would be good to have a list on the wiki which lists the compiler features that we kind of rely on these days, even in case we degrade functionality, like constructor/destructors or the deprecation macros; saying "your compiler needs to have a gcc compatibility layer in order to support GLib" is a bit meh as a policy — especially since we did already accommodate non-gcc in some cases. right now it's not trivial for users of GLib, as well as for compiler developers, to know what we use or provide in terms of support for compiler features. having a canonical place to point people at would help in bug reports, for instance.
(In reply to comment #4) > on that note, it would be good to have a list on the wiki which lists the > compiler features that we kind of rely on these days, even in case we degrade > functionality, like constructor/destructors or the deprecation macros fwiw, constructor support is currently a hard requirement -- but this requirement was only added with knowledge of the fact that we could soften it in the future by adding a check at the various possible first-entry points to GObject in order to emulate the effect. that said, we currently have outstanding bugs about suncc and xlc support for constructors...
Here's a beginning: https://wiki.gnome.org/Projects/GLib/CompilerRequirements
this can be closed now, I think