Brandon> I've gotten a few tests to build by G_INLINE_FUNC to be empty Brandon> before including the .c file. Another approach would be moving the Brandon> include of the .c file up to the top of the test, so G_IMPLEMENT_INLINES Brandon> is set from the beginning, but that's not entirely foolproof either Brandon> because it might break if we need to link a test together from a few Brandon> source files that all try this trick.
Brandon> Another option would be redefining G_INLINE_FUNC to pick up the value of Brandon> G_IMPLEMENT_INLINES at the point of use rather than where glib is first Brandon> included. Something like this seems to behave, as long as you Brandon> only define G_IMPLEMENT_INLINES to be 1 or empty Brandon> #define G_INLINE_FUNC GIF_DELAY(G_IMPLEMENT_INLINES) Brandon> #define GIF_DELAY(X) GIF_TEST(X) Brandon> #define GIF_TEST(X) GIF_##X Brandon> #define GIF_1 extern inline Brandon> #define GIF_ extern inline Brandon> #define GIF_G_IMPLEMENT_INLINES Brandon> (GIF_DELAY is to get around some wierdness in the behaviour of ##). Sorry I don't get it. Why must you use these obscure glib macros at all? Why can't you simply declare your functions hard "static inline"? -- "It's not true or not." A reality show producer (real quote) _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
