GNOME Bugzilla – Bug 511975
g_assert must not use new function
Last modified: 2008-06-16 05:40:05 UTC
We've been burned by this once before. If we change the expansion of a (widely used) existing macro to include new api, hell breaks loose, because suddenly recompiling anything using the macro against a new glib silently adds a dependency against the new glib version. I've seen several problems of this kind in rawhide recently that were caused by g_assert(). Please revert the change to make g_assert and g_assert_not_reached use the new g_assertion_message... functions. If you have to have a g_assert that variant that does that, name it something else, say, g_assert_expr() and g_abort_if_reached()
Umm, hasn't it always been so that compiling against some $current_version headers, regardless if the code actually uses API introduced in $curent_version, still potentially causes a run-time dependency on $current_version? I would say, if one wants to be sure one depends only on some $old_version, then compile against $old_version's headers.
Yeah, basically. But if you play this trick with widely used macros, the pain is considerable.
Also g_assert moved to a completely different header with no backwards compatibility. For example inkscapes src/attributes.cpp ends up including glib/gmessages.h to get g_assert definition. Now with glib-2.16 it fails compilation because glib/gmessages.h does not provide a definition for g_assert anymore and does not include directly or indirectly the header that does either. And including gtestutils.h in gmessages.h isn't a good solution at this point either, as gtestutils.h happily includes the whole of glib.h loosing the whole point that inkscape is doing (including just the header that provides g_assert instead of the whole of glib.h)
Selectively including individual headers has never been supported. You are supposed to include glib.h
This was in line with the widely used aspect. gmessages.h was a header that included g_assert and some other debugging facilities, that some things use only. I'm fine with it staying the same - inkscape has gone fixing it meanwhile (but my understanding is they still include individual headers). Thanks for stating that's not supported and I'll go bother inkscape guys about that instead. Meanwhile we are getting big uproars about everything breaking subtly on a glib downgrade to 2.14, i.e this bug.
Too late now, I guess.