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
