|
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
|
