Minor update:
On 2015-04-29 08:05 (+0200), su_v wrote:
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).
houz helped me solving the problem how to find GTK2 installed into custom prefix: 1) works: setting the env variable $GTKMM_BASEPATH to the custom MacPorts prefix (in the shell where cmake is run) 2) the module FindGTK2.cmake distributed with Inkscape is outdated (it does not support the Quartz backend of GTK2); this has been fixed upstream in cmake. Removing the outdated copy in Inkscape's CMakeScripts/Modules forces cmake to use the newer version it installed itself (works).
Now on to the remaining issues (as in: fix wrongly detected include dirs and libs from unrelated locations, still fails to link, support for GTK+/Quartz hasn't been added to Inkscape's cmake files yet, etc.)
Cheers, V