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?
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?
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?
John
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
