On Dec 16, 2007 2:55 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > On Dec 16, 2007 1:54 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > > On Sunday 16 December 2007, Brandon Van Every wrote: > > > > > > 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.
Possibility (4) has occurred to me. The OO question, and the somewhat related "syntax nicety / maturity" question, may not be nearly as important as supporting the correct IDEs well. For instance, Eclipse. In that world view, the choice of extension language(s) is a political decision, not a technical one. When I peruse http://www.ohloh.net/tags/make I notice that most of the Popular! make-like tools have a particular implementation language associated with them. If you want a make written in Java, you use Ant. If you want it in Ruby, you use Rake. If you want it in C/C++, you use either CMake or GNU Autoconf + GMake. And so on for PHP, Python, etc. For any given implementation language, there's not a lot of variety. Maven 2 seems to have deliberately excluded itself from the "make-like tool" category, so that will be the subject of another post. Anyways; political decisions for supporting Eclipse. How do you avoid offending a Java programmer? Well, if you're not going to write anything in Java, perhaps there is no way. Perhaps instead you cast your lot with the C/C++ Eclipse users and support it that way. Which makes scripting languages moot / orthogonal / detrimental? Or maybe you look to see whether Python, Ruby, or Lua is winning the Eclipse support wars. If none of those are winning, perhaps you wait for a winner to emerge before committing. It doesn't always pay to be in the vanguard of capabilities. Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake