2015-03-22 1:05 GMT+01:00 Bryce Harrington <bryce@...961...>:
To me, the key requirements are perhaps less technical:
Is it widely known? Can we expect distros and businesses using Inkscape to already know it? How likely will new developers coming to the project already know it?
Will mastery of it benefit the engineer for their work beyond our project? Will it be worthwhile for gsoc students to learn? Will we be able to use the skill in our own day jobs?
Is it portable to a wide range of systems? At a minimum it should support Windows/OSX/Linux. Mobile (Android/iPhone/Tizen) portability would give us future flexibility.
Surely Python is more widely known than the CMake scripting language, and learning Python is more generally useful than learning the CMake language.
Waf works everywhere Python is available, so the third point shouldn't be a problem.
Sure, python is a great scripting language, but one could argue if you need a full bore scripting language to build your software, you've got a more serious problem than choice of build systems...
You already need a very complex program to build your software: the compiler. Adding some scripts on top of that doesn't significantly change the situation, and having a real scripting language at your disposal is useful more often than one would expect.
Killer feature: since Waf stores a database of what was compiled, it support wildcards correctly. As in, when the set of files matched by a wildcard in the build script changes, it will automatically recompiles the correct files, without the need to modify build scripts. CMake cannot do this, because it just generates makefiles, and Make cannot support wildcards in this manner because it does not have any persistence beyond what is stored in the file system.
Other things we could easily do with Waf are:
- render test integration
- automatically updating the AUTHORS file and the authors tab in the
About dialog from Bazaar logs
- creating a completely standalone executable (using e.g. GResource to
store data files in the executable itself)
My suspicion is all those things could probably be done one way or another with any build system. ;-)
And by going with cmake, there's a good chance someone's already sorted out how to do it, and we can just reuse their work. ;-)
Wildcards cannot be properly supported by anything that generates makefiles.
For example, let's say you have a program which is compiled from main.cpp, plugin-a.cpp, plugin-b.cpp and plugin-c.cpp. The plugin files add some objects to a container by using static initialization (this is a common pattern and is also used in our own code). Let's say you don't want plugin-c.cpp anymore and you delete it. When using CMake or Autotools, which ultimately rely on make, it would not cause a relinking, because all prerequisites still have timestamps that are earlier than the one on the program executable. By contrast, Waf will correctly trigger a relinking in this case.
CMake can generate for other targets, but I'm not sure whether it supports wildcards for them.
Other things I mentioned could be done with other build systems, but doing them in CMake would require very long scripts, compared to maybe a few lines with Waf; and more people would be able to implement those nontrivial things, because more people are proficient in Python.
I encourage others to look at this file to get an impression of what Waf scripts look like. This one is sufficient to replicate our current Autotools-based build process: http://bazaar.launchpad.net/~tweenk/inkscape/waf-build/view/head:/wscript
Regards, Krzysztof