GTK & GIMP & --enable-ansi

[Raphael Quinet eed ericsson se (Raphaël Quinet)]

I'm sending this to the gtk-list and gimp-dev list because the problem
comes from dependencies between the configure options of GTK and GIMP,
and I am not sure about which package should solve the problem...

Here is the story: since the release of GIMP-1.0.0, I have been
re-installing the latest versions of GTK and GIMP on many
machines/networks.  Usually, I configure both with --enable-ansi
because this allows me to see if I am adding any non-portable code
before submitting some patches.  But on one of the systems on which I
do not have root access, a recent version of GTK was already installed
and the GIMP configure script accepted it without problems.  Alas, the
compilation failed for the following plug-ins: blur, destripe, emboss,
gfli, nlfilt, ps, randomize, sinus, zealouscrop.

These errors were caused by the "inline" keyword, because GTK was
configured with --disable-ansi (I did not know it at that time) and
GIMP was configured with --enable-ansi.  As a result, the "#define
inline" did not work correctly and the compilation failed.

I think this is a long-standing bug in GTK/GIMP, and I remember seeing
it a long time ago.  I had not seen it for a while because I always
configured GTK and GIMP with the same options, but I got hit this time
with a pre-installed GTK.  Note that the compilation works fine if
both are configured with --disable-ansi, both with --enable-ansi, or
if GTK is configured with --enable-ansi and GIMP with --disable-ansi.

The main problem comes from the fact that the configure script for the
GIMP (or any other GTK application) has no way to know if GTK was
configured with or without --enable-ansi.

It would be possible to avoid this problem by adding an AC_TRY_COMPILE
with a small program that includes the GTK headers and uses the inline
keyword.  But I don't like this solution, because this implies that
the configure script of a GTK application would have to undo and redo
what GTK is supposed to do correctly in the first place with "#define
inline..."

Has anybody thought about a good solution to this problem?

-Raphael