FESCo Proposal for blocking older version of autoconf & automake

[Ralf Corsepius]

On Thu, 2008-05-08 at 15:54 -0500, Bruno Wolff III wrote:
> On Thu, May 08, 2008 at 15:47:36 -0400,
>   Christopher Aillon <caillon at redhat.com> wrote:
> >
> > I really don't think upstream has any real objections to moving to a more 
> > modern system, be it new autotools, or a different system altogether 
> > PROVIDED THEIR REQUIREMENTS ARE MET.  The big requirement that nobody has 
> > solved yet is "must work in every case and on every platform it does now".
>From what I say from a "short and hasty glance" into mozilla's
configure.in is them exploiting autoconf-2.13 internals, incorrectly
using certain some autoconf details and having overloaded it with
details which do not belong into configure script.

I.e. the first step to do would be to clean up their configure script
and remove the historic ballast.

> > I don't know whether cmake is as portable as gmake is, but you're free to 
> > discuss that with them.
It isn't. It essentially is imake in new clothes and suffers from the
same fundamental backdraws. 

cmake is nice for simple stuff and when Windows<->Linux support is
important, but that's it. For more complex stuff things very easily grow
nasty.

> One project that is trying to change away from autotools is Wesnoth. They
> are in the process of implementing scons and cmake build systems and will
> later choose between them for going forward. Currently scons is pretty
> complete. The cmake implementation was doing some stuff, but there were still
> some important missing pieces.
Matches with my experience. 

In particular, for my work, cross-compilation is essential and there
neither cmake nor scons are competitive

> So in another month or two, you might be able to get an informed opinion
> from those guys. And people do build Wesnoth on Windows so there is some
> signifcant cross platform testing.
Native Windows support is one domain, the autotools have deficiencies,
but supporting MinGW, Cygwin and MacOS support comes along as almost
"no-cost" side-effect in many cases.

scons is a whole set of problems on its own. Their number one problem is
it being a script-based buildsystem and not a make-based system, which
makes it hardly comparable to the autotools, cmake etc.

Ralf