On Sun, Mar 2, 2008 at 9:10 AM, James Mansion <[EMAIL PROTECTED]> wrote: > > > > Well, I suppose you don't have to use CMake. Perhaps scons would be a > > better fit for your tastes. > > > In a Python-based system, yes. > > But if I have a C++ code and a variety of value added components aimed > at different users, then I can hardly tell Java customers to use Scons, > any more than I could reasonably ask Python customers to use ant.
I don't agree with you in the case of Java. JRake is based on JRuby and is used to build Java apps. I'm not quite sure I understand the build problems of the Java universe. They are certainly not the same as the C/C++ universe, as the behavior of Java implementations is far more unified. I have read that Ant suffers from a lack of scriptability. It was written in an era where everyone thought XML was God, and it turns out in practice that people need more traditional scripted control constructs. I think they currently have some ugly way of hacking it into Ant. Meanwhile, JRake is fulfilling an open niche with a better design. I think it makes a difference that Ruby is perceived as a "better" language than Java. CMake script would be perceived as a "worse" language. Actually from a language sales standpoint it would be more strategic to move CMake to Ruby rather than Lua. The liabilities of Ruby are that it's the slowest of the popular scripting languages, it's not reputed to be particularly easy to embed, and it's Artistic Licensed. Lua on the other hand is the fastest of the popular scripting languages, is designed to be easy to embed, and is MIT licensed. > > Wow, now I need CMake, Ruby, Python, and Tcl just to build this set > > of software. This is just the type of thing CMake was designed to avoid. > > Then probably that is because those projects use Ruby AND Python AND Tcl > - so I have to have them anyway. Hey, lets all use C89. Everyone has > that, right? What if it is just C/C++ code? And the open source author likes Python better than Lua? So he does his build in Python, and now I have to have a Python interpreter just to build his C/C++ code. Either CMake bloats with an interpreter for every scripting language out there, or the user has to install Python for not much of a good purpose. I think the ease of the end user is more important than the ease of the developer in this case. > I like CMake. But the language is impenetrable, I've penetrated CMake script. The documentation is what needs a clearer path. BTW I've bought the current edition of "Mastering CMake" and have yet to read it. I don't really need it because I learned everything the hacker way, through trial and error. Again, I'd really love your comments at http://cmake.org/Bug/view.php?id=6295 "Document core syntax in a chapter format." > verbose, if(clause) else(clause) endif(clause) is verbose, I'll grant you that, but Bill just solved that problem to everyone's satisfaction 1 day ago. I don't think the KEYWORD arg arg paradigm is verbose, I think it's descriptive. It's like having a lot of method calls chained together in 1 interface rather than typing object-->keyword(arg) all the time, as one would in an object oriented language. Perhaps you don't like foreach(blah) endforeach(blah). I'll grant you that's verbose; I suppose it could be relaxed also, if it hasn't been already by Bill's patch. Any other items of particular verbosity you're referring to? > and basically > poor - it can't quite decide whether to declaratve/functional or > imperative, Even OCaml doesn't have functional purity as a goal. Viewing the available CMake script commands as an API, I haven't had an actual, real world problem with how that API is laid out. I think because it has been iteratively refined under years of actual use. > has limited data type or structure support I agree that some type safety would be nice. Especially for lists and semicolons. > - or modularity or reuse support. Well, CMake 2.6.0 does have functions and scope. What more is needed? > It has the appearence of something that had modest > objectives to start with and has evolved. That's quite natural, but > eventually you have to say 'Enough!'. I dunno, I'm still waiting to hear what a Python, Ruby, or Lua based build system can do that CMake can't. People perceive that they can do more, or should be able to do more, but I haven't seen it demonstrated. It may be out there, and I'm open to being shown, but I haven't seen it. I'm hoping someone will demonstrate it, to push Kitware towards a decision on Lua. But if a language is a language is a language, then it seems reasonable to continue polishing CMake script. > I like CMake for what it does, but not the way it does it. If you are > saying that compatibility with the naivety of the past when the macro > language was being used for less ambitious things then fine. But don't > expect that to stop us thinking that a) the language design sucks and b) > of all the alternatives, Lua would seem to be the best fit in terms of > its own dependencies and the cleanliness of the language itself. Careful, you may get what you wish for! I've advocated Lua primarily for marketing and documentation reasons. I know, as you do, that lots of people look at CMake script and say, "this sucks." One research item I haven't undertaken, is how many people say Lua sucks? Are there things about Lua that drive some users batty enough to jump ship for something else? Is Lua wart-free? Do programmers just like to complain endlessly no matter what the language? Are technical solutions the answer to that problem, or is marketing and documentation a better answer? I think these are questions of degree. I think any of the mainstream scripting languages will be more accepted than CMake script. I caution, however, that if we build it and expect people to come, these sorts of issues may not go away. They may have to be handled by marketing and political means. That's an avenue that the CMake community has put very little effort into. I'm not going to point fingers, as I precipitated the cmake-promote mailing list once upon a time and have done very little since then. Too busy coding like most programmers are. I'm just trying to make a pitch for humanistic rather than technical solutions to some of these problems. Techies tend to overlook anything that isn't tech. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
