On 2015-04-29 24:00 (+0200), Alex Valavanis wrote:
== Portability == We need to determine whether the CMake builds work well on OS X and Windows systems. Any comments from users of those systems would be greatly appreciated.
Summary (Mac OS X 10.7.5): ========================== - configuration failure - build failure (with current poppler) - link failure (compilation itself succeeds without poppler) It is unknown at this point what changes will be required for actual packaging (configuring as osxapp, adding whatever tasks for packaging were handled via autotools to Cmake config files, updating build scripts)
Question: ========= Before I go into details (you can skip anything below this paragraph if not interested): does anyone know a GTK+ project of the size of Inkscape, with a similar range of supported platforms, which does use cmake, and does have a current port in MacPorts?
Local setup: ============ MacPorts [1] uses '/opt/local' as default prefix unless installed from source and configured with a different prefix.
In order to be able to build inkscape with both available GTK+ backends on OS X (X11, Quartz), it is required to install two separate MacPorts trees into different (i.e. custom) prefixes (they do not share any files, nor know about each other; one has to take care to never mix the environments in the current shell). Inkscape - using the existing, working build system - then can be configured at build time with either of the two prefixes for the dependencies.
The ultimate goal of this (time-consuming) exercise is to be able to investigate, test&compare and hopefully one day provide what so many Mac users expect from the project (and nothing else): Inkscape for OS X without X11 dependency and with better OS integration.
Current autotools handle such setups ok - dependencies are retrieved via pkg-config in $PATH, nothing outside is pulled in unintentionally or uncontrollably. Inkscape's configure.ac and Makefiles help with that (for example: they don't pull in '-lX11' unnecessarily if not using X11 [2]).
Testing Cmake with trunk (r14067): ================================== Build setup (Gtk+/Quartz 2.24.27, no X11 dependencies): ## Prefix for required packages: $ echo $MP_QUARTZ_PREFIX /Volumes/magenta/mp-trunk/quartz $ echo $PATH /Volumes/magenta/mp-trunk/quartz/bin:/Volumes/magenta/mp-trunk/quartz/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/su_v/.local/bin ## Cmake is installed in $MP_QUARTZ_PREFIX $ type -p cmake /Volumes/magenta/mp-trunk/quartz/bin/cmake $ cmake --version cmake version 3.2.1 ## which pkg-config is used? $ type -p pkg-config /Volumes/magenta/mp-trunk/quartz/bin/pkg-config
## new branch in local shared repo: $ bzr branch lp:inkscape inkscape-cmake ## we want to build out-of-source $ mkdir cmake-build $ cd cmake-build ## run plain cmake $ cmake ../inkscape-cmake ## or run cmake with Ninja ## cmake ../inkscape-camke -G Ninja
Results: (default Unix-Makefiles or Ninja did not make a difference) ======== 1) complete failure to find anything related to gtk/gtkmm and deps:
GTK2_CAIROMMCONFIG_INCLUDE_DIR:PATH=GTK2_CAIROMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GDKCONFIG_INCLUDE_DIR:PATH=GTK2_GDKCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GDKMMCONFIG_INCLUDE_DIR:PATH=GTK2_GDKMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GIOMMCONFIG_INCLUDE_DIR:PATH=GTK2_GIOMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GLIBCONFIG_INCLUDE_DIR:PATH=GTK2_GLIBCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GLIBMMCONFIG_INCLUDE_DIR:PATH=GTK2_GLIBMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_GTKMMCONFIG_INCLUDE_DIR:PATH=GTK2_GTKMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_PANGOMMCONFIG_INCLUDE_DIR:PATH=GTK2_PANGOMMCONFIG_INCLUDE_DIR-NOTFOUND GTK2_SIGC++CONFIG_INCLUDE_DIR:PATH=GTK2_SIGC++CONFIG_INCLUDE_DIR-NOTFOUND
Even after manually setting these variables correctly (why does cmake not use pkg-config to find out about those packages?), there were still two left which I didn't find in ccmake (even in advanced mode), and thus had to to be set directly in CMakeCache.txt:
//Path to a library. GTK2_GDK_LIBRARY:FILEPATH=GTK2_GDK_LIBRARY-NOTFOUND
and
//Path to a library. GTK2_GTK_LIBRARY:FILEPATH=GTK2_GTK_LIBRARY-NOTFOUND
2) failure to support poppler >= 0.29: The latest inkscape build breakage due to a new poppler release (0.29) isn't handled by current CMake configuration (latest poppler version installed locally: 0.32)
3) random and opportunistic detection of dependencies: On closer inspection of CMakeCache.txt, it seems that the detection of required packages is based on some (to me inexplicable) mixture of searching in hard-coded presumed "default" paths, with occasional mixed-in results which can only have been retrieved via (or preferred from results returned by) pkg-config.
Some required dependencies are thus referenced from different locations (paths), without any apparent logic. This also includes opportunistically pulling in libraries installed by XQuartz (the OS X port of X.org), even for a build setup which neither depends on X11, nor uses it.
Affects for example:
- freetype:
//Path to a file. FREETYPE_INCLUDE_DIR_freetype2:PATH=/usr/X11R6/include/freetype2
//Path to a file. FREETYPE_INCLUDE_DIR_ft2build:PATH=/Volumes/magenta/mp-trunk/quartz/include/freetype2
//Path to a library. FREETYPE_LIBRARY:FILEPATH=/Volumes/magenta/mp-trunk/quartz/lib/libfreetype.dylib
- libxml2:
//Path to a file. LIBXML2_INCLUDE_DIR:PATH=/Volumes/magenta/mp-trunk/quartz/include/libxml2
//Path to a library. LIBXML2_LIBRARIES:FILEPATH=/usr/lib/libxml2.dylib
//Path to a program. LIBXML2_XMLLINT_EXECUTABLE:FILEPATH=/Volumes/magenta/mp-trunk/quartz/bin/xmllint
- libxslt:
//Path to a library. LIBXSLT_EXSLT_LIBRARY:FILEPATH=/usr/lib/libexslt.dylib
//Path to a file. LIBXSLT_INCLUDE_DIR:PATH=/usr/include
//Path to a library. LIBXSLT_LIBRARIES:FILEPATH=/usr/lib/libxslt.dylib
//Path to a program. LIBXSLT_XSLTPROC_EXECUTABLE:FILEPATH=/Volumes/magenta/mp-trunk/quartz/bin/xsltproc
For all of the above examples, the preferred (and in my view correct) version would be the one which is installed in the local prefix (i.e. as found by pkg-config in $PATH).
4) linker failure: The initial attempt (plain cmake and make), as well as a second attempt with cmake+ninja failed in the end with the same linker error after compilation itself was successful (poppler had been disabled in ccmake since the installed version is not supported with cmake-based builds):
ld: library not found for -lpangocairo-1.0 clang: error: linker command failed with exit code 1 (use -v to see invocation)
I haven't further investigated yet (nor any idea) where this error originates from - linking just works as expected with autotools-based builds (with either backend).
5) There are likely plenty of details not mentioned above - I'm not familiar with cmake myself, and have yet to learn even the most basic aspects of this build system.
Comments: ========= The major issue I encountered in this initial attempt (apart from the linker failure) is that cmake-based builds seem to prefer to look in hard-coded paths for packages. While it is true that my local test build setup does not use "default" locations (for a reason), I don't think that the build system overall should pose such a limitation to the user.
Ideally, I'd like to learn from cmake-experts how to either prepend search paths (mostly for GTK2-related packages) or change default prefixes via command line when calling cmake, or - if this is not supported by cmake's default Modules or the custom copies which are shipped with inkscape - how to best modify them in such a way that the required changes can be integrated in local build scripts (manually tweaking the config via ccmake or CMakeCache.txt each time is not an option).
hth, V