Hello Alex,
I've attached a diff with re-ordered headers here: https://bugs.launchpad.net/inkscape/+bug/1181928
Getting the same build errors as previously attached.
Samuel
On Thu, May 16, 2013 at 7:32 PM, Alex Valavanis <valavanisalex@...400...> wrote:
Hi All,
Just a quick note about a common source of build failures (e.g., bug #112274) [1].
Basically, we disable the use of deprecated GNOME library symbols wherever possible so that we can avoid big API migration projects in future. A common problem, however, is that some of the C++ bindings (e.g., glibmm and gtkmm) use some of those deprecated symbols!
In other words:
Inkscape ----> glibmm ----> deprecated stuff in glib ---> glib ---> gtkmm ----> deprecated stuff in gtk+ ---> gtk+
So, even though we don't use deprecated stuff ourselves, we still need to take a little care with this!
The solution is to ** Ensure that high-level dependencies are included in our source before low-level dependencies **
For example, the Glib::Thread API in glibmm depends on deprecated GThread stuff in glib.
We will get a build failure if we do the following...
#include <glib.h> #include <glibmm/threads.h>
This is because the deprecated GThread stuff in <glib.h> will be hidden by the C++ preprocessor. When <glibmm/threads.h> is subsequently included, GThread stuff will therefore appear to be undeclared and we get an error like this:
/usr/include/glibmm-2.4/threads.h:142:11: error: field ‘gobject_’ has incomplete type /usr/include/glibmm-2.4/glibmm/threads.h: In member function ‘GThread* Glib::Threads::Thread::gobj()’:
The solution is to do the inclusions in this order:
#include <glibmm/threads.h> #include <glib.h>
This now compiles correctly because when <glibmm/threads.h> itself includes <glib.h>, it temporarily re-enables the deprecated stuff, uses it, and then disables it again.
A couple of additional notes:
- There's actually no need to #include <glib.h> after one of the
<glibmm/*.h> headers... it is already pulled into our source by the glibmm header!
- Remember that you have to avoid *any* inclusion on <glib.h> before
using a <glibmm/*.h> header. As such, it's safest to just put the C++ headers at the top of any source file: i.e.,
// Gtkmm/Glibmm headers first... #include <gtkmm/aaa.h> #include <gtkmm/bbb.h> #include <glibmm/ccc.h> #include <glibmm/ddd.h>
// Now include Inkscape stuff... #include "ui/dialog/wibble.h" #include "ui/dialog/wobble.h"
- Ultimately, we can probably get rid of all direct usage of <glib.h>
and Gtk+ headers and replace them with their respective C++ binding headers.
Cheers,
AV
[1] https://bugs.launchpad.net/inkscape/+bug/1122774
AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel