Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
2013-10-01 10:38, John Emmas skrev: Since I posted that originally, I've encountered one or two other situations where I needed to add either 'glibmm/arrayhandle.h' or 'glibmm/value.h' to a particular .hg file. It's probably for exactly the same reason that you just described above. Would you like to be kept informed about these, if and when I find them? John No, I don't want to be informed about more missing includes in gtkmm 2. I once ran glibmm/tools/test_scripts/testheaders.sh on gtkmm-2.24.3, with code generated by a new version of gmmproc. The result is in the attachment at https://bugzilla.gnome.org/show_bug.cgi?id=697835#c22. It was decided that it should not be implemented. Instead gtkmm-2.24.4 was made with the same old version of gmmproc that had been used for gtkmm-2.24.2. Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 29/09/2013 17:55, Kjell Ahlstedt wrote: 2013-09-17 09:11, John Emmas skrev: 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::ArrayHandlestd::string,AtomStringTraits ArrayHandle_AtomString; typedef Glib::ListHandlestd::string,AtomStringTraits ListHandle_AtomString; In gtkmm 3 neither Glib::ArrayHandle nor Glib::ListHandle occurs in types.hg. Thanks Kjell, Since I posted that originally, I've encountered one or two other situations where I needed to add either 'glibmm/arrayhandle.h' or 'glibmm/value.h' to a particular .hg file. It's probably for exactly the same reason that you just described above. Would you like to be kept informed about these, if and when I find them? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
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::ArrayHandlestd::string,AtomStringTraits
ArrayHandle_AtomString;
typedef Glib::ListHandlestd::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
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 16/09/2013 14:35, Kjell Ahlstedt wrote:
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.
Thanks for the explanation Kjell. That does clarify the situation somewhat.
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 due course I suppose I might find a few similar tweaks here and there
but everything seems to be building well at the moment - and of course I
could always go back to the tarball sources if all else fails.
John
From f787eb2c849604ec59eb9b620598d52500716825 Mon Sep 17 00:00:00 2001
From: John Emmas john...@tiscali.co.uk
Date: Tue, 17 Sep 2013 07:55:33 +0100
Subject: [PATCH] JOHNE - Add some missing include headers to main.hg (gtkmm)
and types.hg (gdkmm)
---
gdk/src/types.hg | 3 +++
gtk/src/main.hg | 1 +
2 files changed, 4 insertions(+)
diff --git a/gdk/src/types.hg b/gdk/src/types.hg
index fd644b8..a046cb1 100644
--- a/gdk/src/types.hg
+++ b/gdk/src/types.hg
@@ -19,6 +19,9 @@
_DEFS(gdkmm,gdk)
+#include glibmm/value.h
+#include glibmm/arrayhandle.h
+#include glibmm/listhandle.h
#include gdk/gdk.h
#include gdkmmconfig.h
diff --git a/gtk/src/main.hg b/gtk/src/main.hg
index c6c05ed..2665445 100644
--- a/gtk/src/main.hg
+++ b/gtk/src/main.hg
@@ -22,6 +22,7 @@
#include sigc++/sigc++.h
#include gdkmm/types.h //For GdkEventKey
+#include glibmm/optioncontext.h
_DEFS(gtkmm,gtk)
--
1.8.0.msysgit.0
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
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 :-( Joh ___ -- Copied from https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00101.html: 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 2.31.0.1 (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 https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00114.html: I have fixed the bugs in _WRAP_SIGNAL, git commit https://git.gnome.org/browse/glibmm/commit/?id=118f894606a1016a15f48a1659ebb29a95f4cdf5. That version of gmmproc inserts both #ifdef GTKMM_ATKMM_ENABLED and #ifndef GTKMM_DISABLE_DEPRECATED at the right locations in both widget.h and widget.cc. 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 https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00101.html. 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/testheaders.sh. 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. Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
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
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 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 ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
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 :-( Joh ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 26/08/2013 08:19, Kjell Ahlstedt wrote: You seem to have a mixture of the master and glibmm-2-36 branches. After I do 'git checkout glibmm-2-36' there is no properties_type anywhere. [...] After 'git checkout master' the string properties_type is found in class.h, class.cc, interface.cc and property.cc. Thanks Kjell. You can safely ignore this thread now. I eventually came to realise that there must have been some kind of technical glitch at my end, since some of my local files didn't match the copies in master (even though I'm 100% certain that I hadn't modified any of them). class.h, interface.h and property.cc were all affected (in each case I seemed to have the previous version of the file, rather than the current version). Strangely though, other files from the same commit were not affected (class.cc, object.cc, objectbase.cc and objectbase.h). Those ones all seem to have updated correctly. BTW - at my end it's not clear when the changes to 'interface.h' and 'property.cc' were committed. The changes are definitely in master but I can't see when they got commited (i.e. I can't find their commits in the git log). It's all a big mystery. I can't even guess at what might have gone wrong but I think I've managed to fix it. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
2013-08-17 19:58, John Emmas skrev: On 17/08/2013 08:31, John Emmas wrote: For those of us who are still building version 2, will you be pushing your fix to the latest 2.24 branch or should I just apply it locally as a patch? Oops - forgive my misunderstanding, Kjell. I assumed this morning that your fix was in gtkmm but I just re-read your email and realised that in fact, it's in glibmm. So, armed with that information, I updated glibmm to pull in your fix. Unfortunately, glibmm itself won't build at the moment because of some problems in class.h, class.cc and interface.cc (all of them, non auto-generated files so I doubt if the problems will be connected to Kjell's fix). In the case of class.h, someone has removed the line #include vector. This means that anything which #includes glibmm/class.h won't compile at the moment (because class.h uses std::vector). Even if I fix that, neither class.cc nor interface.cc will compile. I get this error when trying to build with MSVC:- error C2039: 'properties_type' : is not a member of 'Glib::Class' That particular error is from line 69 of glibmm/interface.cc. AFAICT the line itself hasn't changed recently - so I assume it's the result of a header file change somewhere. Hope someone can make sense of it.! John Sorry for the delay in replying. I've had a one-week break from from glibmm/gtkmm. This is really strange. When I look at the latest version of class.h in the git master branch, https://git.gnome.org/browse/glibmm/tree/glib/glibmm/class.h I see at line 28 #include vector //For properties that custom types might override. and at line 105 typedef std::vectorGValue* properties_type; Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
Hi Kjell, hope you had a nice break! I think I might be able to shed some light onto this On 25/08/2013 07:32, Kjell Ahlstedt wrote: This is really strange. When I look at the latest version of class.h in the git master branch, https://git.gnome.org/browse/glibmm/tree/glib/glibmm/class.h I see at line 28 #include vector //For properties that custom types might override. and at line 105 typedef std::vectorGValue* properties_type; In my case I'm having to use glib v2. Therefore I'm building glibmm from its branch glibmm-2-36, rather than from master. In glibmm-2-36, it looks like glib/glibmm/class.h doesn't yet have those changes. 'properties_type' has been pushed to the relevant source files - but not yet pushed to class.h. Hope that helps. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 25/08/2013 08:53, John Emmas wrote: In my case I'm having to use glib v2. Therefore I'm building glibmm from its branch glibmm-2-36, rather than from master. In glibmm-2-36, it looks like glib/glibmm/class.h doesn't yet have those changes. Hmmm... this is all a bit strange. Firstly, I was slightly mistaken in my original report. glibmm-2.36 is in fact our current 'stable' branch. I can switch between it and master. But even if I switch to master and pull the latest code I still don't see those changes you mentioned in 'glib/glibmm/class.h'. Two things 1) The current version number (for master) is 2.37.5. Is that the same as yours? 2) In my current working copy 'class.h' is NOT an auto-generated file. Is that still the case or should I be auto-generating it now? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 25/08/2013 11:11, John Emmas wrote: even if I switch to master and pull the latest code I still don't see those changes you mentioned in 'glib/glibmm/class.h'. Two things 1) The current version number (for master) is 2.37.5. Is that the same as yours? 2) In my current working copy 'class.h' is NOT an auto-generated file. Is that still the case or should I be auto-generating it now? Okay, this might be making a little bit of sense here. If I select 'glib/glibmm/class.h' and I ask git to show me a diff between my current version and the previous version, those lines you mentioned (Kjell) seem as if they've been deleted. But if I then look at the blame log for that file, there's no name against who deleted them. To me, this suggests that git itself might have deleted them, thinking it was resolving a conflict. :-( I can easily put them back. It looks like there's been some kind of glitch at my end. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 16/08/2013 08:05, Kjell Ahlstedt wrote: I have fixed the bugs in _WRAP_SIGNAL, git commit https://git.gnome.org/browse/glibmm/commit/?id=118f894606a1016a15f48a1659ebb29a95f4cdf5. That version of gmmproc inserts both #ifdef GTKMM_ATKMM_ENABLED and #ifndef GTKMM_DISABLE_DEPRECATED at the right locations in both widget.h and widget.cc. Unfortunately it's still not easy to build gtkmm-2.24.4 with that newest version of glibmm/gmmproc. Hi Kjell, For those of us who are still building version 2, will you be pushing your fix to the latest 2.24 branch or should I just apply it locally as a patch? (at the moment, it looks like your fix is only pushed to version 3 master). John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 17/08/2013 08:31, John Emmas wrote: For those of us who are still building version 2, will you be pushing your fix to the latest 2.24 branch or should I just apply it locally as a patch? Oops - forgive my misunderstanding, Kjell. I assumed this morning that your fix was in gtkmm but I just re-read your email and realised that in fact, it's in glibmm. So, armed with that information, I updated glibmm to pull in your fix. Unfortunately, glibmm itself won't build at the moment because of some problems in class.h, class.cc and interface.cc (all of them, non auto-generated files so I doubt if the problems will be connected to Kjell's fix). In the case of class.h, someone has removed the line #include vector. This means that anything which #includes glibmm/class.h won't compile at the moment (because class.h uses std::vector). Even if I fix that, neither class.cc nor interface.cc will compile. I get this error when trying to build with MSVC:- error C2039: 'properties_type' : is not a member of 'Glib::Class' That particular error is from line 69 of glibmm/interface.cc. AFAICT the line itself hasn't changed recently - so I assume it's the result of a header file change somewhere. Hope someone can make sense of it.! John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
2013-08-14 10:20, John Emmas skrev: On 13/08/2013 19:07, Kjell Ahlstedt wrote: *_WRAP_METHOD* #ifndef has deliberately been moved. New versions of gmmproc puts both comment and function declaration inside #ifndef/#endif. That's the right thing to do. If xxx_DISABLE_DEPRECATED is defined when the module is built (--disable-deprecated-api) Doxygen shall not include the description of deprecated functions in its generated documentation. I understand. Yes, that seems like a sensible approach. *_WRAP_SIGNAL* The deprecated parameter was previously ignored, but new versions of gmmproc generates #ifndef xxx_DISABLE_DEPRECATED directives. Unfortunately the #ifndef directive is written in the middle of comment, if there is a manually added comment in the .hg. And another bug, introduced at the same time: The ifdef GTKMM_ATKMM_ENABLED parameter in _WRAP_SIGNAL is ignored. I'll try to fix both these bugs. Many thanks, Kjell. It'll probably be an easy fix for you to test but if you need any help with the testing, I'm happy to volunteer. With regard to the ignored parameter (#ifdef GTKMM_ATKMM_ENABLED), please be aware that it's not only widget.hg which suffers from the problem. The generated 'widget.cc' also had at least three occurrences where #ifdef GTKMM_ATKMM_ENABLED needed to be present (but it either wasn't present - or it said GTKMM_DISABLE_DEPRECATED instead of GTKMM_ATKMM_ENABLED). These were at lines 3162, 7555 and 8485. As far as I know though, widget.cc and widget.h are the only problematic files. The rest of gtkmm seems to be okay. Hope that helps. John I have fixed the bugs in _WRAP_SIGNAL, git commit https://git.gnome.org/browse/glibmm/commit/?id=118f894606a1016a15f48a1659ebb29a95f4cdf5. That version of gmmproc inserts both #ifdef GTKMM_ATKMM_ENABLED and #ifndef GTKMM_DISABLE_DEPRECATED at the right locations in both widget.h and widget.cc. 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. Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 13/08/2013 19:07, Kjell Ahlstedt wrote: *_WRAP_METHOD* #ifndef has deliberately been moved. New versions of gmmproc puts both comment and function declaration inside #ifndef/#endif. That's the right thing to do. If xxx_DISABLE_DEPRECATED is defined when the module is built (--disable-deprecated-api) Doxygen shall not include the description of deprecated functions in its generated documentation. I understand. Yes, that seems like a sensible approach. *_WRAP_SIGNAL* The deprecated parameter was previously ignored, but new versions of gmmproc generates #ifndef xxx_DISABLE_DEPRECATED directives. Unfortunately the #ifndef directive is written in the middle of comment, if there is a manually added comment in the .hg. And another bug, introduced at the same time: The ifdef GTKMM_ATKMM_ENABLED parameter in _WRAP_SIGNAL is ignored. I'll try to fix both these bugs. Many thanks, Kjell. It'll probably be an easy fix for you to test but if you need any help with the testing, I'm happy to volunteer. With regard to the ignored parameter (#ifdef GTKMM_ATKMM_ENABLED), please be aware that it's not only widget.hg which suffers from the problem. The generated 'widget.cc' also had at least three occurrences where #ifdef GTKMM_ATKMM_ENABLED needed to be present (but it either wasn't present - or it said GTKMM_DISABLE_DEPRECATED instead of GTKMM_ATKMM_ENABLED). These were at lines 3162, 7555 and 8485. As far as I know though, widget.cc and widget.h are the only problematic files. The rest of gtkmm seems to be okay. Hope that helps. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 12/08/2013 21:39, John Emmas wrote: Thanks Kjell. That bug report suggests that Kalev has already produced a new tarball for 2.24.4 which includes the correct (i.e. older) version of gmmproc. No, I was mistaken. The tarball doesn't include any version of gmmproc. Presumably Kalev just built it against an older version of glibmm? If that's the case, I should be able to solve this problem by switching glibmm to an older branch. But which one?? Anyone know? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
2013-08-13 08:01, John Emmas skrev: On 12/08/2013 21:39, John Emmas wrote: Thanks Kjell. That bug report suggests that Kalev has already produced a new tarball for 2.24.4 which includes the correct (i.e. older) version of gmmproc. No, I was mistaken. The tarball doesn't include any version of gmmproc. Presumably Kalev just built it against an older version of glibmm? If that's the case, I should be able to solve this problem by switching glibmm to an older branch. But which one?? Anyone know? John The change of #include directives (from glibmm.h to glibmm/ustring.h and sigc++/sigc++.h) was done in the unstable glibmm version 2.31.0.1. You should use an earlier version, and preferably a stable one, e.g. 2.30.1. It's a pity that the bug report does not tell which version was used for gtkmm 2.24.4. Only very new versions of gmmproc print their version at the top of the generated files. One problem with _WRAP_SIGNAL(Glib::RefPtrAtk::Object get_accessible(), ...) is that there is no such signal in gtk+. get_accessible is a virtual function, and not a signal. In widget.hg get_accessible has both a _WRAP_SIGNAL and a _WRAP_VFUNC. Still there is something wrong with gmmproc. It shall not put #ifndef GTKMM_DISABLE_DEPRECATED in the middle of a comment. Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 13/08/2013 08:17, Kjell Ahlstedt wrote: The change of #include directives (from glibmm.h to glibmm/ustring.h and sigc++/sigc++.h) was done in the unstable glibmm version 2.31.0.1. You should use an earlier version, and preferably a stable one, e.g. 2.30.1 Thanks Kjell, The most recent stable version I could find on the gtkmm web site was 2.28.2 I installed it onto a separate drive so I could experiment with it. However, that version of gmmproc doesn't seem to understand Windows paths. If I use forward slashes - e.g. -I D:/Temp/glibmm-2.28.2/glib/src it gives me the error:- -ID is not recognized as an internal or external command. OTOH if I use backslashes and supply an absolute path - e.g. -I D:\Temp\glibmm-2.28.2\glib\src I get this message:- The file name, volume name or directory name syntax is incorrect. Finally, if I supply backslashes with a relative path I get the error:- The system cannot find the path specified. So for the time being, it looks like I'll just have to build gtkmm from a tarball. Building from Git sources doesn't seem to be possible for now :-( John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
2013-08-13 10:28, John Emmas skrev: On 13/08/2013 08:17, Kjell Ahlstedt wrote: The change of #include directives (from glibmm.h to glibmm/ustring.h and sigc++/sigc++.h) was done in the unstable glibmm version 2.31.0.1. You should use an earlier version, and preferably a stable one, e.g. 2.30.1 Thanks Kjell, The most recent stable version I could find on the gtkmm web site was 2.28.2 I installed it onto a separate drive so I could experiment with it. However, that version of gmmproc doesn't seem to understand Windows paths. If I use forward slashes - e.g. -I D:/Temp/glibmm-2.28.2/glib/src it gives me the error:- -ID is not recognized as an internal or external command. OTOH if I use backslashes and supply an absolute path - e.g. -I D:\Temp\glibmm-2.28.2\glib\src I get this message:- The file name, volume name or directory name syntax is incorrect. Finally, if I supply backslashes with a relative path I get the error:- The system cannot find the path specified. So for the time being, it looks like I'll just have to build gtkmm from a tarball. Building from Git sources doesn't seem to be possible for now :-( John There are many glibmm versions in the subdirectories of http://ftp.gnome.org/pub/GNOME/sources/glibmm/ Do you know which program prints those error messages? gmmproc? The perl interpreter? Another program? I can't find any of those three messages in the source code of gmmproc. (I admit that I have searched in the latest git version of gmmproc, and not in version 2.28.2.) In what context are those paths specified? A typical call to gmmproc from a Makefile in glibmm/glib/src in my Ubuntu Linux system is /usr/bin/perl -I../../tools/pm -- ../../tools/gmmproc -I ../../tools/m4 --defs . balancedtree . ../glibmm A typical call to gmmproc from a Makefile in gtkmm/gtk/src is /usr/bin/perl -I/opt/gnome/lib/glibmm-2.4/proc/pm -- /opt/gnome/lib/glibmm-2.4/proc/gmmproc -I ../../tools/m4 -I /opt/gnome/lib/pangomm-1.4/proc/m4 -I /opt/gnome/lib/atkmm-1.6/proc/m4 --defs . widget . ../gtkmm Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 13/08/2013 15:34, Kjell Ahlstedt wrote: There are many glibmm versions in the subdirectories of http://ftp.gnome.org/pub/GNOME/sources/glibmm/ Yeah, I just picked 2.28.2 because it was stated as being the most recent stable version. I don't mind trying the others but I can imagine it being a long job :-( Do you know which program prints those error messages? gmmproc? The perl interpreter? Another program? If I had to make a guess I'd guess at M4 (only because it usually says M4 aborting after the error messages). I reckon that guess is pretty safe though, because although M4 itself hasn't changed, the contents of 'glibmm/tools/M4' are greatly different between the old glibmm (v2.28.2) and the latest version (v2.37.4). A typical call to gmmproc from a Makefile in gtkmm/gtk/src is /usr/bin/perl -I/opt/gnome/lib/glibmm-2.4/proc/pm -- /opt/gnome/lib/glibmm-2.4/proc/gmmproc -I ../../tools/m4 -I /opt/gnome/lib/pangomm-1.4/proc/m4 -I /opt/gnome/lib/atkmm-1.6/proc/m4 --defs . widget . ../gtkmm In my case I'm building on Windows. My equivalent command for building gtkmm/gtk/src looks like this:- perl -IF:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/pm F:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/gmmproc -I F:/+GTK-SOURCES/gnu-windows/src/MB3Gtkmm/tools/m4 -I F:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/m4 -I F:/+GTK-SOURCES/gnu-windows/src/MB3Atkmm/codegen/m4 -I F:/+GTK-SOURCES/gnu-windows/src/MB3Pangomm/tools/m4 --defs . widget . ../gtkmm I've split the command across several lines just for clarity. It's probably worth mentioning two things:- 1) Firstly, the same basic command (suitably modified) can be successfully used to build glibmm, atkmm and pangomm. Only gtkmm is causing any problems. 2) Secondly, that funny quirk (where the #ifndef got put inside a comment) isn't the only example of that happening. In fact, there seems to be a general problem if a comment happens to precede a preprocessor directive. The preprocessor directive seems to get put before the comment (whereas if I look at the same files from a tarball) the comment usually comes first and the preprocessor directive second. In that quirky example from 'widget.h' there are 3 comments immediately preceding the preprocessor directive. I suspect that might have something to do with the problem. Hope this all helps. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
2013-08-13 17:21, John Emmas skrev: On 13/08/2013 15:34, Kjell Ahlstedt wrote: In my case I'm building on Windows. My equivalent command for building gtkmm/gtk/src looks like this:- perl -IF:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/pm F:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/gmmproc -I F:/+GTK-SOURCES/gnu-windows/src/MB3Gtkmm/tools/m4 -I F:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/m4 -I F:/+GTK-SOURCES/gnu-windows/src/MB3Atkmm/codegen/m4 -I F:/+GTK-SOURCES/gnu-windows/src/MB3Pangomm/tools/m4 --defs . widget . ../gtkmm I've split the command across several lines just for clarity. It's probably worth mentioning two things:- 1) Firstly, the same basic command (suitably modified) can be successfully used to build glibmm, atkmm and pangomm. Only gtkmm is causing any problems. Sorry, I don't understand why gtkmm fails in this way. And it fails in another way with a new version of glibmm. If you think it's worth more trouble-shooting, can you send a more complete input and output? I don't understand if the paths you showed in a previous mail (like -I D:/Temp/glibmm-2.28.2/glib/src) is just an example of the type of path you used (absolute path with slashes in this case), or if it's the exact path used in a command. At first I thought is was exactly the path you used in some command, but now I'm not so sure. 2) Secondly, that funny quirk (where the #ifndef got put inside a comment) isn't the only example of that happening. In fact, there seems to be a general problem if a comment happens to precede a preprocessor directive. The preprocessor directive seems to get put before the comment (whereas if I look at the same files from a tarball) the comment usually comes first and the preprocessor directive second. In that quirky example from 'widget.h' there are 3 comments immediately preceding the preprocessor directive. I suspect that might have something to do with the problem. Hope this all helps. *_WRAP_METHOD* #ifndef has deliberately been moved. New versions of gmmproc puts both comment and function declaration inside #ifndef/#endif. That's the right thing to do. If xxx_DISABLE_DEPRECATED is defined when the module is built (--disable-deprecated-api) Doxygen shall not include the description of deprecated functions in its generated documentation. *_WRAP_SIGNAL* The deprecated parameter was previously ignored, but new versions of gmmproc generates #ifndef xxx_DISABLE_DEPRECATED directives. Unfortunately the #ifndef directive is written in the middle of comment, if there is a manually added comment in the .hg. And another bug, introduced at the same time: The ifdef GTKMM_ATKMM_ENABLED parameter in _WRAP_SIGNAL is ignored. I'll try to fix both these bugs. Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
It depends on which version of glibmm (and thus gmmproc) you use. The same bug is mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=697835#c16 (glibmm version unknown). https://bugzilla.gnome.org/show_bug.cgi?id=697835#c21 shows a different result with glibmm 2.32.0. The gtkmm 2.24.4 tarball shows a third result (glibmm version unknown). All of https://bugzilla.gnome.org/show_bug.cgi?id=697835 discusses problems with gtkmm 2.24.3. Version 2.24.4 was released as a result of those problems. It rurned out that it's important to use the correct version of glibmm (gmmproc). Unfortunately I can't find it mentioned in the bug what version of glibmm is the correct one to use. Does anyone know? Can't you use the tarball? Nothing has been added to git branch gtkmm-2-24 since tarball gtkmm 2.24.4 was released. Kjell 2013-08-12 17:38, John Emmas skrev: I'm building gtkmm on Windows (using MSVC). Rather than building from a tarball I'm using the git sources (which means me having to build all the auto-generated stuff, using gmmproc etc). Everything builds pretty well. I've even built glibmm, atkmm and pangomm the same way. The only hiccup I seem to have is with the file 'gtk/src/widget.hg' At line 3546 in the finished file (widget.h) I seem to end up with this code:- //Note that the deprecated keyword has no effect on _WRAP_SIGNAL() yet. //It doesn't seem like a good idea to put virtual functions in #ifdefs, because that would change the size of the class instances. /** @deprecated This should never have been in the API. It was never meaningful. * #ifndef GTKMM_DISABLE_DEPRECATED * @par Slot Prototype: * ttGlib::RefPtrAtk::Object on_my_%get_accessible()/tt * */ Glib::SignalProxy0 Glib::RefPtrAtk::Object signal_get_accessible(); #endif // GTKMM_DISABLE_DEPRECATED Note that the line ' ifndef GTKMM_DISABLE_DEPRECATED is getting generated inside a comment. In any case, I think it's the wrong #define. Looking at the hg file it looks as if the correct line should have been #ifdef GTKMM_ATKMM_ENABLED . I don't really understand the format of a hg file but from a simple observation of 'widget.hg' I can see that the declaration which corresponds to the mis-generated code seems to be the only occurence of #ifdef GTKMM_ATKMM_ENABLED which has the word deprecated after it. Might that explain the problem?? This is with version 2.24.4, cloned from Git just a couple of days ago. John __ ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 12/08/2013 18:25, Kjell Ahlstedt wrote: It depends on which version of glibmm (and thus gmmproc) you use. The same bug is mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=697835#c16 (glibmm version unknown). https://bugzilla.gnome.org/show_bug.cgi?id=697835#c21 shows a different result with glibmm 2.32.0. The gtkmm 2.24.4 tarball shows a third result (glibmm version unknown). All of https://bugzilla.gnome.org/show_bug.cgi?id=697835 discusses problems with gtkmm 2.24.3. Version 2.24.4 was released as a result of those problems. It rurned out that it's important to use the correct version of glibmm (gmmproc). Unfortunately I can't find it mentioned in the bug what version of glibmm is the correct one to use. Does anyone know? Thanks for the quick response Kjell. It's getting a bit late in my part of the world (and I've had a long day!) but I'll be sure to follow up those leads tomorrow. FWIW my copy of gmmproc is only about 2 weeks old (dated 27 Jul 2013) and comes from glibmm version 2.37.4 Can't you use the tarball? Nothing has been added to git branch gtkmm-2-24 since tarball gtkmm 2.24.4 was released. Yes, I can definitely use the tarball if all else fails but it'd be nice to see a fix so that the hg file can get built correctly. BTW 'widget.cc' also seems to suffer from a similar problem when auto-generated :-( John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
You're right, the latest version of glibmm (gmmproc) generates erroneous code. I thought it was an old version that did that. This is something I should look into, I think. 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 2.31.0.1 (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. Kjell 2013-08-12 20:04, John Emmas skrev: On 12/08/2013 18:25, Kjell Ahlstedt wrote: It depends on which version of glibmm (and thus gmmproc) you use. The same bug is mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=697835#c16 (glibmm version unknown). https://bugzilla.gnome.org/show_bug.cgi?id=697835#c21 shows a different result with glibmm 2.32.0. The gtkmm 2.24.4 tarball shows a third result (glibmm version unknown). All of https://bugzilla.gnome.org/show_bug.cgi?id=697835 discusses problems with gtkmm 2.24.3. Version 2.24.4 was released as a result of those problems. It rurned out that it's important to use the correct version of glibmm (gmmproc). Unfortunately I can't find it mentioned in the bug what version of glibmm is the correct one to use. Does anyone know? Thanks for the quick response Kjell. It's getting a bit late in my part of the world (and I've had a long day!) but I'll be sure to follow up those leads tomorrow. FWIW my copy of gmmproc is only about 2 weeks old (dated 27 Jul 2013) and comes from glibmm version 2.37.4 Can't you use the tarball? Nothing has been added to git branch gtkmm-2-24 since tarball gtkmm 2.24.4 was released. Yes, I can definitely use the tarball if all else fails but it'd be nice to see a fix so that the hg file can get built correctly. BTW 'widget.cc' also seems to suffer from a similar problem when auto-generated :-( John ___ ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: auto-generated file 'gtkmm/widget.h' (widget.hg)
On 12 Aug 2013, at 20:32, Kjell Ahlstedt wrote: You're right, the latest version of glibmm (gmmproc) generates erroneous code. I thought it was an old version that did that. This is something I should look into, I think. 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 Thanks Kjell. That bug report suggests that Kalev has already produced a new tarball for 2.24.4 which includes the correct (i.e. older) version of gmmproc. Is it possible that the older version just needs to be added to ver 2.24.4 in Git? Or isn't it as simple as that? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
