On Wed, Apr 29, 2015 at 05:46:05PM +0200, su_v wrote:
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 probably already helped you with all of this, but in general I find that 'cmake -L' is handy for finding what settables there are, and then 'cmake -D<param>=<val>' to set them.
We should include some examples of common kinds of configuration in our README or INSTALL document.
The way the cmake Find modules work, essentially we just give them lists of directories to look for specific header files or library files. So, if for Mac you use a non-default location, but one which other users might use as well, there's no reason we couldn't add that to the given Find module's path list. So if it helps Mac or Windows packaging to have packages built at, say, /opt/inkscape-dependencies or C:\devpkgs123, or whatever, then certainly add those paths to our Find modules to help make life easier.
houz helped me solving the problem how to find GTK2 installed into custom prefix:
- 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).
Yes. As it's been a while since cmake was introduced to our repository, likely all the modules in our tree have bitrotted to some degree. These should all be refreshed. Also, I wonder if some of them we can use from cmake directly and not include them in our tree?
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.)
I have been messing with it too, and notice the dependencies for a number of extensions haven't been set up, or were set up as optional. I'm going to be checking in some changes to make them required so that the tree builds on ubuntu. We'll want to give these some more attention in time, so that disabling the dependency disables building the respective extension(s) and so on.
Bryce