[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
If you're gonna have more than one build system, the devs should use a
build system that builds all the build systems. You should not
maintain more than one system, even if you support more than one. I am
a fan of the DRY principle, Don't Repeat Yourself.
On Sat, Feb 7, 2009 at 7:52 AM, Jon Rafkind <workmin@xxxxxxxxxx> wrote:
> 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
>