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

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

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