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

2013-09-16 10:03, John Emmas skrev:
On 16/09/2013 08:29, Kjell Ahlstedt wrote:

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.

Thanks again Kjell. I'm not averse to using the tarball. It's just a pity because I'm building the entire gtk stack Including related libraries such as freetype, pixman, pango etc - all built from their git sources. gtkmm is the only one which I can't build that way. It just seems a shame that it can't be fixed.

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.

Presumably, that would then give me problems when building glibmm?
Yes, if you try to build the latest version of glibmm with an old version of gmmproc (which is actually part of glibmm) it will probably give you other problems.

2. Use the newest version of gmmproc, but undo the change mentioned in
You will have to change glibmm/tools/m4/base.m4.

And that would bring back the original errors that I reported when building and widget.h?
No. You just need to replace
  #include <glibmm/ustring.h>
  #include <sigc++/sigc++.h>
  #include <glibmm.h>
in base.m4 a few lines after

The problem with misplaced and missing #ifdef/#ifndef directives in widget.h and is unrelated to this change.

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.

That's a possibility I suppose....

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.

Maybe I'm missing something here - but if glibmm needs version X of gmmproc while gtkmm needs version Y, wouldn't it be sensible for each library to contain the specific version that it needs? Or to put it another way, why does gtkmm need to use the glibmm version of gmmproc? Why can't it have a self-contained version for its own use?
gmmproc is part of glibmm. I don't know if that's optimal, but it has worked well in most cases. It causes problems here, because you use gtkmm 2. I suppose you're forced to do that because there is still no gtkmm 3 (or gtk+ 3) version that runs on Windows. The maintenance of gtkmm 2 has almost come to an end, while the development of glibmm 2 continues. I think these problems would never have occurred if gtkmm 3 had been accompanied by a new major release of glibmm, glibmm 3. Then the latest release of glimm 2 (including gmmproc) would have been compatible with the latest release of gtkmm 2. No glibmm 3 version has been released, because there is no glib 3 release.


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