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@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
