[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On February 11, 2009, Anders Andersson wrote:
> 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.
Hehe, luckily cmake does that for you. It creates makefiles and project files
for various setups.
> 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
>
> ---------------------------------------------------------------------------
>--- 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
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx