[CMake] Waf build tool

[Brandon Van Every]

On Dec 16, 2007 1:54 PM, Alexander Neundorf <a.neundorf-work at gmx.net> wrote:
>
> On Sunday 16 December 2007, Brandon Van Every wrote:
> > On Dec 16, 2007 1:11 PM, Gonzalo Garramuño <ggarra at advancedsl.com.ar> wrote:
> > > Brandon Van Every wrote:
> > > > Waf is the offering of a fellow
> > > > who clearly thinks OO is important in a build system for some reason.
> > > > http://code.google.com/p/waf/
> > >
> > > A quick eval of waf....
> >
> > Ok, waf sucks.  It can't demonstrate anything compelling about OO
> > build systems in practice.  But does it say anything about OO build
> > systems in theory?  Does the author have a good idea?
> >
> > Meanwhile I just keep expanding my search radius, asking various build
> > system communities "the OO question."
>
> What's the purpose ?
> CMake is kind-of going OO.

The purpose is to understand what benefits OO has, if any, for build
systems.  Then to understand whether Lua, Python, or Ruby offer those
benefits.  Then to understand whether CMake "kinda implementing
something like OO" also provides those benefits.  Possible futures for
build systems in general:

1) OO approaches really don't matter.  "Make"-style tools were the
right way to do things all along.  In industrial practice, nobody ever
moves away from Make, because the industrial continuity of Make-style
development is paramount over any marginal benefit that OO provides.

2) OO approaches do prove to matter in some arenas.  Perhaps
integration with IDEs or XML or some such, as the Waf author seems to
think?  Or whatever.  Make-style systems and OO systems exist side by
side, each in their own areas of greatest applicability.

3) OO approaches prove to matter greatly as software reaches a certain
level of complexity.  Industry moves en masse to OO build systems,
retiring their 1990s legacy Make systems.

Which future do you think it will be?  If you assume (1), then in 10
years you could get left behind.  So my goal is not to assume, but to
go out there and understand.  Alternately, if (1) really is the
future, we can learn how to make CMake be the best possible (1).  We
should not, however, assume that we're great and that everyone who's
trying something else is dumb.


Cheers,
Brandon Van Every