On Dec 16, 2007 1:54 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > > On Sunday 16 December 2007, Brandon Van Every wrote: > > On Dec 16, 2007 1:11 PM, Gonzalo Garramuño <[EMAIL PROTECTED]> 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 _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
