On Dec 18, 2007 4:08 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > > Missing: > -ant: I think having an ant generator might be nice [...] > It would also mean that CMake > generates ("modern") XML files instead of ("old fashioned") Makefiles. > -any others ?
If someone wants to do Ant, and they're really really motivated, then they'll do Ant and I imagine CMake won't refuse their work. However, I'm not presently convinced that Ant, Maven 2, or XML-based build systems in general, are strategic. Although widely deployed, there are some indications that the Java universe doesn't think they're so hot after all. Wiser people have recognized that you really do need conditional logic to do a build system, and that hacking conditionals within the constraints of XML is extremely clunky. This is the origin of JRake, Raven, and Groovy. I would watch these tools, and similar, to see what kind of progress they make. If we had a crystal ball, we'd really like to know who's going to win the "how do you script Java?" wars. There are many offerings. No clear winners. In the same vein I'm thinking it's premature to commit to Lua. It may be more important to commit to whatever the Java universe commits to. Consider, for example, that embedding Ruby and shipping with possibly 4MB of source file bloat, would be acceptable if it emerged as the clear slam dunk de facto standard for building Java apps. But that wouldn't be for several years yet, if ever. I can't tell whether Raven is a really important project, or just 2 guys getting a lot of notoriety because nobody else is doing anything. Their mailing list certainly has a lot of crickets chirping. At some point next year I imagine we'll see what they're capable of. The performance differences between Python, Ruby, and Lua may also change in the next few years. People have worked on speeding Python and Ruby up. Maybe someone will finally succeed? I think migration technologies in general are worth investing in. This is a more technologically advanced proposition than hanging one's hat on Python, Ruby, or Lua and hoping that OO will confer competitive advantages. I think the money is tied up in moving from old build systems to new build systems, and making that job less labor intensive. I don't have any thoughts yet on what an ideal migration technology would look like. When I look at the Tiobe list of popular languages http://www.tiobe.com/tpci.htm , none of the top 20 languages are interesting as a basis for migration technology. With the possible exception of Lisp/Scheme. This says to me that industry doesn't know how to metaprogram. I do follow the Microsoft Research offerings a little bit. Perhaps they will push one of their languages into popularity. I think superior documentation and tutorial technologies are part of superior migration technologies. Many things could be done here. Often not the sort of thing that techies like to do though. > ------------------------ > CMake features > ------------------------ > > better regexps wouldn't hurt Related: introduce bool type, remove boolean pollution from strings (Y, N, YES, NO, ON, OFF). Grabbing small character sequences to mean TRUE or FALSE is an unclean practice; I've demonstrated the errors it can introduce. NOTFOUND is a large character sequence and not so problematic. General mechanism for future-looking behaviors, so that we're not forever stuck with the argument "it'll break backwards compatibility. > I could create a wiki page "TODO items" so interested people may pick > something to work on. Not sure that helps. Anything I suggested, I can implement. Others might get to it faster, and choose to run with it, but if no one else cares, I certainly will. I haven't met a lot of open source people who will just work on any old thing. Maybe such people exist, and maybe it's possible to marshal them into various things. But I think more is needed than a TODO list, to accomplish that. Someone has to actually lead on any given feature. This is why projects often use a bug tracker to organize this kind of stuff. The problem with a bug tracker is it doesn't tell you at-a-glance what people are working on. What we really need is a way to dump that information out of the bug tracker and display it on a webpage. Would this be as simple as defining a particular Mantis view, and then making a wiki page about using Mantis to examine that view? Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake