Matthew Leverton wrote:
On Fri, Feb 6, 2009 at 8:50 AM, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
No, it doesn't. Having one build system that works everywhere makes
sense and is less likely to break one of them.
Maintaining two build systems for a code base that is in flux is not a
good idea from a maintenance point of view, as the example of the
Scons build falling so far behind that it no longer works and is
(temporarily?) dropped should illustrate.
My opinion is that there should only be a single build system,
regardless if people volunteer to maintain another one. If there is
only a single build system, then that will always be kept up-to-date
because obviously it must for the library to be built.
From a users perspective I am very sympathetic to the frustration of
not being able to build a project. For whatever reason there is often a
chance that the build system provided by a project will not build on
someone's machine. In that case its nice to have an alternative build
system that might work. Let's assume scons was the primary build system
for allegro. Some people hate python.. ok, they can use cmake.
Alternatively some people hate cmake. Ok, they can use scons.
SCons failed mostly because it doesn't contain the infrastructure
required for the complexities of Allegro. It is an elegant model and
fundamentally more powerful than cmake because it uses a powerful
language as its description language. CMake has a lot of handy stuff
built in that makes it convenient to use whereas most of that stuff has
to be built by the users of SCons, which I didn't feel like doing.
Ultimately I feel that cmake is an incremental improvement over
autotools/make in that it gives the user a more powerful toolbox, but
the toolbox is still limited. When you want to do something outside the
scope of the toolbox your choices are to write a program (sh, C,
whatever) or ask the cmake people to extend the toolbox. Maybe Allegro
will never reach the limits of the cmake toolbox, I don't know, and I'm
sure some workaround will be found anyway.
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
https://lists.sourceforge.net/lists/listinfo/alleg-developers