On Tue, Aug 5, 2014 at 2:06 PM, Simon McVittie < simon.mcvit...@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 >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
