On 05/08/14 18:43, Victor Aurélio Santos wrote: > +1 for waf, I currently use it in my projects, it's features are very > good/cool and it extensibility is very simple, basically as you have > told.
The Autotools are not without their flaws, but they have also solved many real-world build problems that other build systems haven't even thought about - in particular, "make distcheck" has saved me from making broken releases on many occasions - and their flaws are at least well-understood by distributions. As far as I can see, CMake is the only other build system that comes close. I personally can't stand it - in particular, best-practice for detecting external packages seems to involve copy/pasting around chunks of repetitive convenience code even though it should be as simple as a call to PKG_CHECK_MODULES - but I know some people like it, and it does work better on Windows. In particular, Linux distributions *hate* waf. One of the reasons is: > Currently waf does basically same thing, you haven't to have waf > installed to build, the 'waf' python script will require only python > installed, as 'configure' requires bash/sh. ... but this results in not having the source code to the build system you're building with in any sane form (the "compiled" waf script is a self-unpacking binary container, containing a copy of waf); and trying to consolidate onto fewer versions of waf within a distribution (i.e. not the precise version that upstream used) is not something that is supported by the authors of waf, because waf build systems that worked fine with one version will not necessarily work with another. The Autotools have the same issue to an extent, but at least their generated files (mainly configure and **/Makefile.in) are text, which you can patch directly if you're sufficiently desperate for a solution to a serious bug. Best-practice in at least Debian and Ubuntu is moving towards always discarding the upstream-supplied configure and Makefile.in, and re-running autoconf/automake to re-generate them during the build; this removes some of the perceived advantages of Autotools, but it means we're compiling from actual source code, not from something that looks vaguely like source code if you aren't really paying attention :-) Non-tarball-based packaging/meta-build systems like jhbuild and gnome-continuous also work from the actual source code. S _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list