> 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.
maybe in the future others build systems implement most of autotools features. the "particular" actually was supported by waf, ie "waf distcheck". > 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. I disagree, I don't see CMake comes close. > ... 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. yeah, this is true, a contra for waf, but since I'm not suggesting waf this doesn't matter. (But I really like waf, and see it as most close alternative. rsrs) > 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 I agree with debian/ubuntu, IMHO this is a best-practice. this also discard the contra of waf. Sorry If I've told much about waf, this is because I see it as most close alternative. (Maybe because it's features and also I love python...) On Tue, Aug 5, 2014 at 4:35 PM, Ross Burton <r...@burtonini.com> wrote: > On Tuesday, 5 August 2014, Simon McVittie <simon.mcvit...@collabora.co.uk> > wrote: >> >> 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 :-) > > > For what it's worth OpenEmbedded has also been doing this for years and not > as "best practise" but as default behaviour. We basically run autoreconf > -sif and have a surprisingly high success rate :) > > Ross > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Victor Aurélio Santos _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
