Re: A Gtk's build system ?

[Victor Aurélio Santos <victoraur santos gmail com>]

> 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 <ross burtonini com> wrote:
> On Tuesday, 5 August 2014, Simon McVittie <simon mcvittie 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