Re: Proposal: Recommend meson for glib 2.58.0
On Fri, 2018-06-08 at 18:59 +0100, Philip Withnall wrote: Hi, > > My proposal would be: > > 1) Starting from 2.57.2 (next dev release), create release tarballs > > using "ninja dist" and recommend disto to build with Meson 0.46.1. > > This would mean that './configure' in a release tarball won't work, > > people still wanting to use autotools will have to update their > > scripts to use "./autogen.sh" instead and adjust their build deps. > > IMHO, forcing a small change is a good incentive to have most of > > our users switch to meson. This would give us good feedback while > > still keeping the door open to rollback if any blocker bug appears. > > 2) Starting from 2.59.1 (next dev cycle), drop autotools completely > > from our git repository. > > How about: > 1) Starting from 2.57.2, create release tarballs with `ninja dist`, > but recommend that distributions still build with autotools (unless > they want to dogfood with Meson early). Just to make sure everyone is aware of this, this also means distros will always need to always build the documentation with gtk-doc, since "ninja dist" won't include generated html files in the tarball. It just includes whatever is checked into git (they could be checked into git of course if that was a deal-breaker for some reason). Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building glib-genmarshal (while building glib)
On Sat, 2017-08-12 at 13:54 +0100, John Emmas wrote: Hi John, > What's happened to 'glib-genmarshal.c'? It seems to have been > removed from git master - although (AFAICT) it doesn't get auto- > generated. A new file does get generated (gobject/glib-genmarshal) > but i can't see how that gets used to generate glib- > genmarshal.c.. What am I missing?? > (I'm building on Windows BTW). It has been rewritten in python, so there's nothing to compile any more. Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: building glib on windows
On Tue, 2015-11-03 at 14:40 +, jcup...@gmail.com wrote: Hi John, > have a look at this: > > https://github.com/nice-software/gtk-win32 > > Hi Ignacio, that looks great, but unfortunately I need to build on > linux and cross-compile :-( > > Does anyone have a link to linux-hosted win64 gtk build system I > could > have a look at? The build system GStreamer uses for this (cerbero) should be able to do that (our windows build bots do that): http://cgit.freedesktop.org/gstreamer/cerbero/ Documentation might be a bit sparse, pop into #gstreamer on FreeNode if you have any questions. Binaries (incl. glib) here: http://gstreamer.freedesktop.org/data/pkg/windows/ People do use these also with MSVC projects, and it mostly works fine at least for GStreamer use cases, but as Ignacio mentioned you might run into unexpected issues when mixing runtimes. Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Broken 'C' compilation when building from Master with MSVC
On Mon, 2015-11-02 at 23:20 +, Emmanuele Bassi wrote: > > inline in C is a C99 feature, which is why older VS doesn't support > > it. VS2015 does. > > I'm pretty sure MSVC versions prior to the one in Visual Studio 2015 > support `static inline` function declarations. MS Visual C++ Express 2010 seems to want __inline instead of inline. Apparently VS 2013 does too: http://stackoverflow.com/questions/24736304/unable-to-use-inline-in-dec laration-get-error-c2054 Which version did you have in mind? Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant singletons
On Thu, 2011-12-08 at 10:15 +, Simon McVittie wrote: > (But seriously: would people be interested in GLib having/installing a > suppressions file that silences many of the one-per-process > "deliberate leaks"? We have an incomplete one in telepathy-glib that would > be a good start.) Yes, definitely. We also maintain GLib/GObject suppressions in GStreamer for our unit tests, would be nice if we could just use an installed suppression file instead. Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
On Thu, 2009-11-26 at 14:35 +0100, Alexander Larsson wrote: > Starting with next glib release: > * libgobject links to libgthread > * g_type_init() starts with: > > #ifdef G_THREADS_ENABLED > if ([!]g_thread_supported()) >g_thread_init (NULL); > #endif > > This means that everything above gobject can rely on thread primitives > being availible, and that global stuff in glib (mainloop, gslice, > globals, etc) are threadsafe. Yes, please! Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, 2009-11-08 at 10:54 +0100, Alexander Larsson wrote: > I've been working on some API for gio (more details later) that involves > having an API for (de)compression. Having this as a public API makes > zlib a mandatory dependency for libgio (and thus the glib tarball). > > (...) > > Anyone who thinks this is a bad idea? I think that's a great idea. Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDateTime
On Sun, 2009-10-04 at 18:07 -0400, Behdad Esfahbod wrote: > > Can we move discussion here: > > https://bugzilla.gnome.org/show_bug.cgi?id=344005 > > Err, I noticed that it's not exactly the same thing, but the two need to be > discussed together. FWIW, there's also https://bugzilla.gnome.org/show_bug.cgi?id=50076 (Time API to go with date API) Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject Introspection support for GSList or other types without a GLib type
On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote: > On libgda, it define a GType for GError and a GSList becouse these > doesn't exist on GLib and it uses them as parameters when creating > properties and events. Great, another library that registers its own GError boxed type. I think I've lost count now. Any chance we could get a boxed type for GError in GLib after all? (see bugs #300610 and #337092) Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTypeModule and threads
On Tue, 2009-06-16 at 11:52 +0200, Jannis Pohlmann wrote: > I played with this a bit more and it seems it's not related to > GTypeModule all. Even if I make the GModule resident and never unuse > the GTypeModule, I still end up with this error. So the question is, is > GType or at least g_object_new() thread-safe? Or if it's not, shouldn't > it be? For what it's worth, GStreamer uses GType/GObject in a heavily multithreaded context fairly successfully, so it should generally work just fine as long as you're aware of a few things: - you need to make sure your _get_type() functions are thread-safe (via g_once_init_enter/leave() or somesuch) - g_object_notify() and by extension g_object_set() are not thread-safe (yet) and bad things will happen if they are concurrently used on the same object+property. A fairly straight-forward patch for this issue is available in bugzilla [1], but is sadly still waiting for review. - you need to do locking internally in your object implementation as needed (e.g. for properties etc.) (hope I didn't forget anything) > Excerpt of the backtrace of the above error: > > #3 0xb7ec0f17 in g_assertion_message () > #4 0xb7ec14dd in g_assertion_message_expr () > #5 0xb7f6458f in g_type_class_ref () > #6 0xb7f49268 in g_object_newv () > #7 0xb7f497b1 in g_object_new_valist () > #8 0xb7f49920 in g_object_new () > > Any help would be greatly appreciated. Seems like I can reduce the risk > of this error to appear by protecting parts of my code with mutexes but > that still isn't 100% safe and it looks to me like this might be a bug > in GObject/GType. This looks a lot like the infamous bug #64764, which was fixed quite some time ago, however. What GLib version are you using? I think the fix made it into 2.16. If this is in fact the same issue, you can work around it by doing a g_type_class_ref(type) at the beginning of your code. Cheers -Tim [1] http://bugzilla.gnome.org/show_bug.cgi?id=166020#c61 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Thu, 2009-04-02 at 20:34 -0400, Havoc Pennington wrote: > > - What of the license issues? > > GLib is LGPL. libdbus-1 is not. (...) > > Just for the record, my comment on this has always been that the > license issues were not earth-shattering to begin with, and the > relicensing was just throwing a bone to people who cared. (...) > > (snip commentary and what-ifs) > > There are many things to worry about in life, but this is not one of them. I hear what you're saying, and I don't really have a strong opinion or much detailed knowledge on the licensing subject myself, but I can't help but feel that there's still something wrong about all this. You tell people not to worry. But many people clearly do seem to worry. It seems to me that by making GLib, the cornerstone of our platform, depend on libdbus, we'd be creating a fair bit of uncertainty, and I can't see that as being good for the platform. At best this means inconvenience and hassle for people already building on our platform while they evaluate the new situation for themselves. At worst it deters people from considering or adopting it. I don't think this is something we'd even be considering if there was a good alternative. Just to be clear, I'm very much in favour of adding DBus support to GLib, I'm just a bit reluctant about shrugging off the dbus license aspect like that. Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib substr function
On Fri, 2009-04-10 at 12:45 +0200, b0unc3 wrote: > there is any implementation of a substr function in GLib ? > > I mean : > string = "hello world" > g_*substr*(string,2,6) > output = llo w substr = g_strndup (string + offset, len); ... g_free (substr); should do the trick (assuming that offset < strlen). Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
