Re: [AD] scons build

[Jon Rafkind <workmin@xxxxxxxxxx>]

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.