Re: A Gtk's build system ?






On Tue, Aug 5, 2014 at 2:06 PM, Simon McVittie <simon mcvittie collabora co uk> wrote:
... 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.

Distributions completely misunderstand the role of waf when they attempt to do this. One of the biggest, most infuriating problems with autotools is the lack of back- and future compatibility, which means that all developers working on a project MUST use very similar versions of the entire autotools stack.

waf was specifically designed to avoid this issue by being a tool that is bundled as part of a PROJECT not as part of a distribution/platform. there is frankly no reason for any distribution to ever package waf. that simply isn't how it is intended to be used.

we've been using waf to build ardour for several years now, and other than the need to add some i18n-generation functionality, it has been far better than any other build i've ever used. we also bundle our own waf extensions inside the ardour source tree as a normal python script and document how to rebuild "waf" if and when necessary (e.g. if there is a decision to move a new version of waf). it is very very easy (and not very common).

the only downside i've come across with waf so far was the initial mental realignment needed to write our own wscript files. waf internally uses some fairly different terminology and some slightly different concepts, and it took me a short time to adjust to this. having done so, i could never go back to the endless series of shell hacks they call autotools. note that we also use waf to build ardour on linux, solaris, OS X and windows. same build system on all platforms. 

 

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]