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

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 :-(

------ Copied from

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 (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

I have fixed the bugs in _WRAP_SIGNAL, git commit That version of gmmproc inserts both #ifdef GTKMM_ATKMM_ENABLED and #ifndef GTKMM_DISABLE_DEPRECATED at the right locations in both widget.h and

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
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/ 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]