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

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

2013-09-15 18:16, John Emmas skrev:
> Hello Kjell,
>
> If you cast you mind back a few weeks you'll remember fixing some 
> auto-generation stuff which hadn't been working properly.  I pulled in 
> your fixes and ran a test build.  Everything seemed to be fine. Today 
> is the first time that I've needed to use the built libraries though 
> (gdkmm and gtkmm).
>
> I don't know if there's still a problem with auto-generation or if 
> some other problem's been introduced somewhere - but when #including 
> gdkmm/types.h in a project I suddenly see the following compiler 
> errors (with MSVC):-
>
> a) (gdkmm/types.h - line 361) - 'ArrayHandle is not a member of Glib'
> b) (gdkmm/types.h - line 362) - 'ListHandle is not a member of Glib'
>
> Likewise, when #including gtkmm/main.h in a project I now see the 
> following error:-
>
> a) (gtkmm/main.h - lines 151 & 204) - 'OptionContext is not a member 
> of Glib'
>
> Sure enough, if I scroll up to the top of 'types.h' (or 'main.h') the 
> relevant header files don't seem to be getting #included.  Can anyone 
> suggest a reason why this problem's suddenly appeared? Given that the 
> files get auto-generated it's difficult to tell what they used to look 
> like previously  :-(
>
> Joh
> _______________________________________________
------ Copied from 
https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00101.html:

Anyway, you will have other problems if you let a new version of gmmproc 
generate code for gtkmm 2.24.4. That's what bug 697835 is all about. 
Gtkmm 2.24.4 (and probably all versions of gtkmm-2) must have its code 
generated by an old version of gmmproc that adds

  #include <glibmm.h>

to all generated .h files. New versions of gmmproc, from 2.31.0.1 
(2011-10-26), adds

  #include <glibmm/ustring.h>
  #include <sigc++/sigc++.h>

That change was done to speed up compilation, but #include directives 
had to be added in many .hg files in gtkmm and other modules.

----------- Copied from 
https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00114.html:

I have fixed the bugs in _WRAP_SIGNAL, git commit 
https://git.gnome.org/browse/glibmm/commit/?id=118f894606a1016a15f48a1659ebb29a95f4cdf5.
That version of gmmproc inserts both #ifdef GTKMM_ATKMM_ENABLED and 
#ifndef GTKMM_DISABLE_DEPRECATED at the right locations in both widget.h 
and widget.cc.

Unfortunately it's still not easy to build gtkmm-2.24.4 with that newest 
version of glibmm/gmmproc. Many of the .hg files in gtkmm-2.24.4 are not 
compatible with new versions of gmmproc, because of the change in 
generated #include directives in the generated .h files (from #include 
<glibmm.h> to #include <glibmm/ustring.h> and #include 
<sigc++/sigc++.h>). That was a deliberate change. As far as I know there 
are no plans to undo it. The .hg files in gtkmm-3 have been adapted to 
the change in gmmproc.

--------- End of copy

Why can't you use the tarball, and refrain from regenerating the .h and 
.cc files? That would be  easier for both of us. Ok, I understand that 
you won't do that, I just don't know why.

There are some alternatives for you:

1. Use an older version of gmmproc, glibmm 2.31.0 or older. That's how 
the tarball for gtkmm 2.24.4 was made.

2. Use the newest version of gmmproc, but undo the change mentioned in 
https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00101.html.
You will have to change glibmm/tools/m4/base.m4.

3. Insert the necessary #include directives in the .hg files, as has 
been done in gtkmm 3.
You can get some help from the shell script 
glibmm/tools/test_scripts/testheaders.sh. It will find the header files 
that need more #include directives, but it won't tell you which files to 
include.

Don't expect a new release of gtkmm 2, compatible with the newest 
releases of gmmproc, or a new release of gmmproc (glibmm), compatible 
with existing releases of gtkmm 2.

Kjell