Thanks for the clarification.
I'm trying to use it on Windows now. - Extra dependency = perl (installed ActivePerl, is free)
- It finds MSVC first, but I can tell it not to do that (how to set the default? CXX env var does not work, as it still thinks that is MSVC...)
- It creates /build. Does it do out-of-source build automatically? That'd be great.
- Now it errors because it cannot find 'glib-mkenums' (indeed, the executable is not in our devlibs)
- I really hope we can set all defaults correctly on Windows, so we can build from a new checkout with the same amount of effort as we do now (almost zero).
Cheers, Johan
On 26-1-2014 20:44, Krzysztof Kosiński wrote:
2014-01-26 Johan Engelen <jbc.engelen@...2592...>:
Hi Krzysz, Great that you are working on unifying the build system again. There is a parallel effort using CMake, which you are aware of of course. CMake is used by many projects, so it may be easier for Inkscapers to start using that. That said, I don't feel very strongly about it.
What I think is important is that the system can target "ninja" or other build systems besides "make". CMake can create makefiles for many targets (makefiles, visual studio, ninja, ...) which is very nice and would be an extra step forward for our buildsystem. Can Waf do the same?
There is some support for generating MS Visual Studio project files, so I guess it would be entirely possible to write a generator for Ninja, but generally the premise of Waf is different than CMake. CMake is a build system generator, while Waf is the build system itself - it replaces 'make' completely.
The biggest advantages of Waf from my perspective:
- It stores file hashes in a database which is persistent over runs,
so you can use wildcards to specify the files to build, and it will figure out on its own that the wildcard includes new files which have to be compiled. This is simply impossible in a system where state information is stored only in file system attributes, such as make.
- The build scripts use Python, which is a real programming language
with very high expressive power. By comparison, programming anything even moderately complex in CMake is a bad joke.
- As a consequence of 2, it is very easy to express complex tasks in
a very small amount of code. Basically everything, from simple building, to maintenance tasks such as updating the potfiles, to release tarball generation can be integrated in the build scripts as Waf commands.
- Since my first attempt, the documentation has improved massively -
there are fairly comprehensive API docs available online.
- I have commit access, so I can immediately fix any bugs we encounter :)
(ninja is speeding up 2geom compiles by an incredible amount, mostly because 2geom has many executable targets (all the toys, etc). Don't know what it will do for Inkscape.)
A no-change rebuild of Inkscape (~1000 tasks) takes around half a second on my machine, which is a lot faster than Autotools (I didn't measure it precisely, but it takes several seconds).
As far as I know, Waf is substantially faster than SCons, Autotools and make, but slower than lower level tools such as Ninja, Gyp and Tup. However, the difference is not very noticeable for projects the size of Inkscape, and IMO this drawback is outweighed by its ease of use.