Re: Gobject-Introspection and CMPH

[John Ralls <jralls ceridwen us>]

On Dec 15, 2010, at 9:21 AM, Colin Walters wrote:

> On Mon, Dec 13, 2010 at 1:35 PM, John Ralls <jralls ceridwen us> wrote:
>> One of the files in the new (to introspection) cmph directory, chd_ph.c, includes an anonymous union which requires -std=gnu99 to compile. Is that OK?
> 
> This would have been better as a bug.  However, if what you're
> *really* asking here is:
> 
> * What's the gtk+/GNOME policy on compilers that we should build with?
> 
> That would be a good subject for a list discussion =)
> 
> What's the actual problem you ran into that caused you to make this
> post (hypothetical example: You are trying to build the stack with
> LLVM, and it doesn't support anonymous unions (it may actually, i'm
> just making this up)).
> 
> Now, if we're trying to say that GTK+/GNOME only requires "C89",
> strictly speaking, we have work to do:
> 
> $ metabuild CFLAGS='-Wall -std=c89'
> metabuild: logging to '/tmp/build-gtk3.log'
> metabuild: Detected Makefile, using it
> metabuild: Running: ['chrt', '--idle', '0', 'nice', 'ionice', '-c',
> '3', '-t', 'make', 'CFLAGS=-Wall -std=c89', '-j', '24']
> make  all-recursive
> make[1]: Entering directory `/src/checkout/gtk3'
> ...
> make[2]: Entering directory `/src/checkout/gtk3/gdk'
> make[3]: Entering directory `/src/checkout/gtk3/gdk'
> make[4]: Entering directory `/src/checkout/gtk3/gdk/win32'
> make[4]: `.gitignore' is up to date.
> make[4]: Leaving directory `/src/checkout/gtk3/gdk/win32'
> make[4]: Entering directory `/src/checkout/gtk3/gdk/quartz'
> make[4]: `.gitignore' is up to date.
> make[4]: Leaving directory `/src/checkout/gtk3/gdk/quartz'
> make[3]: Leaving directory `/src/checkout/gtk3/gdk'
> make  all-recursive
> make[3]: Entering directory `/src/checkout/gtk3/gdk'
> Making all in x11
> make[4]: Entering directory `/src/checkout/gtk3/gdk/x11'
>  CC     gdkapplaunchcontext-x11.lo
>  CC     gdkasync.lo
>  CC     gdkcursor-x11.lo
>  CC     gdkdevice-core.lo
>  CC     gdkdevicemanager-core.lo
>  CC     gdkdevicemanager-x11.lo
>  CC     gdkdisplay-x11.lo
>  CC     gdkdnd-x11.lo
>  CC     gdkeventsource.lo
>  CC     gdkgeometry-x11.lo
>  CC     gdkeventtranslator.lo
>  CC     gdkglobals-x11.lo
>  CC     gdkim-x11.lo
>  CC     gdkinput.lo
>  CC     gdkkeys-x11.lo
>  CC     gdkmain-x11.lo
>  CC     gdkproperty-x11.lo
>  CC     gdkscreen-x11.lo
>  CC     gdkselection-x11.lo
>  CC     gdkspawn-x11.lo
>  CC     gdktestutils-x11.lo
>  CC     gdkvisual-x11.lo
>  CC     gdkwindow-x11.lo
>  CC     gdkxftdefaults.lo
>  CC     gdkxid.lo
>  CC     checksettings.o
> checksettings.c: In function ‘main’:
> checksettings.c:43:7: error: expected expression before ‘/’ token
> 
> make[4]: *** [checksettings.o] Error 1
> make[4]: *** Waiting for unfinished jobs....
> make[4]: Leaving directory `/src/checkout/gtk3/gdk/x11'
> 
> Now, obviously C++ comments in C files are pretty easy for other
> compilers to implement.  But it's hard to know what other GNU C
> extensions the GTK+ stack uses with without fixing those.  Are there
> any nested functions for example in GTK+?  I'd be surprised, but you
> never know...
> 
> The CMPH situation for g-i is special in a few ways because it's an
> import of sort-of-maintained code, and I really don't want to be in
> the business of diverging too far.  I should probably invest in axing
> out a lot of the code that isn't used, but it's nontrivial.
> 
> Bottom line here - if there's a use case you think should be
> supported, *explain what it is*, and let's discuss getting a buildbot
> set up.

I wanted to know whether I should file a bug on cmph not compiling when I feed it -std=c99 (almost everything else,
including gtk+, builds happily with c89, so no, it doesn't have nested functions) or just change the gtk-osx jhbuild module to use gnu99. 

I guess you answered the question, so I'll write a patch and file a bug... but probably not till early next week, as we're releasing Gnucash 2.4.0 this weekend and I've some work to do there first.

But since you bring it up, what is the "official" policy? Is it C89? Is it published somewhere?

Regards,
John Ralls