2013-09-17 09:11, John Emmas skrev:
After some further experimentation yesterday, your suggestion #3 looks
very promising:-
3. Insert the necessary #include directives in the .hg files, as
has been done in gtkmm 3.
I discovered that only a few, very small additions to just two .hg
files were needed to make this work. I've attached a patch to this
email but really, it's very similar to the stuff that's already in
gtkmm 3 ('gtk/src/main.hg' is identical, in fact). After applying the
patch to my 2.24 branch locally, I can now build the gtk / gtkmm stack
again, as well as our app which uses it.
One thing that's of interest is my patch to 'gdk/src/types.hg'. gtkmm
3 has the following #include already added:-
#include <glibmm/value.h>
whereas I found that I actually need 3 x extra #includes, like so:-
#include <glibmm/value.h>
#include <glibmm/arrayhandle.h>
#include <glibmm/listhandle.h>
If I don't include those extra two lines, gdkmm itself will build okay
- but I can't build an external project that uses it. I imagine that
the same would be true for gtkmm 3 (i.e. those two extra lines should
get added there too).
In gtkmm 2 types.hg contains the lines
typedef Glib::ArrayHandle<std::string,AtomStringTraits>
ArrayHandle_AtomString;
typedef Glib::ListHandle<std::string,AtomStringTraits>
ListHandle_AtomString;
In gtkmm 3 neither Glib::ArrayHandle nor Glib::ListHandle occurs in
types.hg.
Kjell
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
