Re: A Gtk's build system ?

[Simon McVittie <simon mcvittie collabora co uk>]

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