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

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

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 https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00101.html.
> > You will have to change glibmm/tools/m4/base.m4.
> And that would bring back the original errors that I reported when 
> building widget.cc and widget.h?
No. You just need to replace
  #include <glibmm/ustring.h>
  #include <sigc++/sigc++.h>
by
  #include <glibmm.h>
in base.m4 a few lines after
  define(`_END',`dnl

The problem with misplaced and missing #ifdef/#ifndef directives in 
widget.h and widget.cc 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/testheaders.sh. 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.
> John