On Dec 17, 2007 10:35 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > people and projects are strongly voting with their feet > despite (and this is an extremely important consideration) virtually > everybody absolutely hating to change build systems.
Here, I think it's more important to concentrate on the lifecycle of build systems, rather than people's emotions about them. The vast majority of software developers don't like build systems no matter what stage of the lifecycle they're at. Most engineers want the build to go away. They don't think it's real code, they think it's pure overhead. They resent having to maintain it. Only when the complexity of their business gets to a certain point, and the inevitable relationship between their build system and their profitability emerges, do they grudgingly take steps to address it. Then after cutting off their fingers some more with half-measures, they grudgingly hire a dedicated build engineer. If a software project continues to grow in complexity and requirements, the build dies. Then there's a (forced) opportunity to replace it with something better. As builds die, engineers look at the available products and decide what the next build is going to be. They may choose something incrementally conservative, i.e. CMake over GNU Automake, which are broadly of the same style. Or they may choose something "apparently cutting edge," if they think it may give them a competitive advantage. Or if the risk is manageable, i.e. they can afford to change their minds again, if the new build doesn't work out. I don't take it as a given that CMake will inherit all GNU Autoconf / GMake projects. Especially not indefinitely, as the next 10 years unfold. It's important to look at competitors and determine what engineers think is attractive in a build tool. Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake