On Dec 14, 2007 8:45 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > On Friday 14 December 2007, Brandon Van Every wrote: > > On Dec 14, 2007 2:38 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > > > It really boils down to this: There is no way we can ever stop > > > supporting the current cmake language. It would be a huge break in > > > backwards compatibility. > > > > Gee I'm getting paid to migrate a huge build system, from ancient > > You're writing this since quite some time already to this list, still not > done ? I hope you're not fiddling around with trying to use cmake as a > programming language...
I'm not trying, I'm succeeding. A primitive translator is simply a pile of regular expressions. I paved over many of the deficiencies in CMake's regular expressions several months ago, using only CMake script. For instance, I implemented a word negation operator. Once CMake has PCRE, that sort of thing won't be needed. > > crufty GNU Autoconf / GMake crap to CMake. Writing a translator to go > > from CMake script to Lua script, both under Kitware's control, would BTW, this doesn't imply the translator would be written in CMake script. It's simply easier to have CMake script, Lua script, and a CMake script --> Lua translator all under one roof, no matter what language the translator is done in. It could be done in Lisp, OCaml, or Haskell if those turned out to be appropriate. > Don't try to write a converter from some buildsystem to cmake *in* cmake. Why not? Just because you don't think it can or should be done, doesn't make it so. I had 4 motives to do it that way. (1) I was only planning to use regular expressions to do the translation, nothing more sophisticated than that. CMake script is perfectly adequate in that regard. One regex interface is pretty much as good as another, the real programming work is done with the regex strings themselves. (2) I knew CMake script and C++, not some other scripting language. I don't see C++ as particularly appropriate to the problem, as it has no inherent regex support and compile-debug cycles are slow compared to scripting. (3) A large body of CMake script could serve as a political inroad with the client. They might realize the extent to which they could use CMake to do system things, instead of Perl or Python or Ruby or whatever people think you're "supposed to" use to solve problems. (4) The choice of language was a throwaway. The most important end product is the new build, not the method used to attain the build. So if CMake script proved to be a really good solution, that's great. If it didn't, no big loss. Of these motives, (3) the political one, was my strongest. Why improve Ruby when I could improve CMake script? > While not as fluent as in > cmake it took me half an hour to do it, in cmake it would have been more > complicated. I've programmed the translator for a few months, not a few hours. If the ruby code you're talking about is what I looked at on the wiki, what I've done is way, way beyond that. > Conclusion: use cmake to build programs, not for writing programs You have no idea what I've done. There's no conclusion to draw. I don't think what I wrote is that great from a long term maintenance standpoint. If I were going to refactor it for ever-more-generalized translation, I'd want the PCRE capabilities. I might even want to use a completely different form of pattern matching, and just reuse the overall design rather than the specific components. But I do believe my approach was cost effective, in terms of dollars spent for translations accomplished. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
