Re: auto-generated file 'gtkmm/widget.h' (widget.hg)

[John Emmas <johne53 tiscali co uk>]

On 13/08/2013 15:34, Kjell Ahlstedt wrote:
> There are many glibmm versions in the subdirectories of 
> http://ftp.gnome.org/pub/GNOME/sources/glibmm/
Yeah, I just picked 2.28.2 because it was stated as being the most 
recent stable version.  I don't mind trying the others but I can imagine 
it being a long job  :-(


> Do you know which program prints those error messages? gmmproc? The 
> perl interpreter? Another program?
If I had to make a guess I'd guess at M4 (only because it usually says 
"M4 aborting" after the error messages).  I reckon that guess is pretty 
safe though, because although M4 itself hasn't changed, the contents of 
'glibmm/tools/M4' are greatly different between the old glibmm (v2.28.2) 
and the latest version (v2.37.4).


> A typical call to gmmproc from a Makefile in gtkmm/gtk/src is
>   /usr/bin/perl -I"/opt/gnome/lib/glibmm-2.4/proc/pm" -- 
> "/opt/gnome/lib/glibmm-2.4/proc/gmmproc" -I ../../tools/m4 -I 
> /opt/gnome/lib/pangomm-1.4/proc/m4 -I /opt/gnome/lib/atkmm-1.6/proc/m4 
> --defs . widget . ../gtkmm
In my case I'm building on Windows.  My equivalent command for building 
gtkmm/gtk/src looks like this:-

perl -IF:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/pm
    F:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/gmmproc
     -I F:/+GTK-SOURCES/gnu-windows/src/MB3Gtkmm/tools/m4
        -I F:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/m4
          -I F:/+GTK-SOURCES/gnu-windows/src/MB3Atkmm/codegen/m4
             -I F:/+GTK-SOURCES/gnu-windows/src/MB3Pangomm/tools/m4 
--defs . widget .  ../gtkmm

I've split the command across several lines just for clarity.  It's 
probably worth mentioning two things:-

1)  Firstly, the same basic command (suitably modified) can be 
successfully used to build glibmm, atkmm and pangomm.  Only gtkmm is 
causing any problems.

2)  Secondly, that funny quirk (where the #ifndef got put inside a 
comment) isn't the only example of that happening.  In fact, there seems 
to be a general problem if a comment happens to precede a preprocessor 
directive.  The preprocessor directive seems to get put before the 
comment (whereas if I look at the same files from a tarball) the comment 
usually comes first and the preprocessor directive second.  In that 
quirky example from 'widget.h' there are 3 comments immediately 
preceding the preprocessor directive.  I suspect that might have 
something to do with the problem.  Hope this all helps.

John