Re: unit testing and G_INLINE_FUNC - breakage moving from 2.4 to 2.6

[Ian Zimmerman <itz buug org>]

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)