> (Aside: what's with the cm_ prefix?) The cm_ prefix was something Ken put in his demo. I assumed he was trying to 'namespace' the thing. I personally like the idea and really think it should have been applied to the regular CMake language. Often when I have to read other people's code, I can't distinguish between the 'official' API functions are and the userland functions when I do not know the official API very well. I certainly had this problem with CMake when I first started out, and I also have this problem with CMake functions that I forget about or don't know about either due to legacy redundancy/obsoletion or new things introduced.
>> As I said, the use of unpack() was > > unnecessary. > > I'm doubting that's correct. I doubt that sources and unpack(sources) > are the same thing at all. So you're not listening. What I said is: cm_add_library( "simpleLib", "STATIC", "simpleLib.cxx", "simpleCLib.c", "simpleWe.cpp") is identical to: sources = {"simpleLib.cxx", "simpleCLib.c", "simpleWe.cpp"} cm_add_library( "simpleLib", "STATIC", unpack(sources)) In both cases, the function cm_add_library receive 5 strings as arguments. I'm also saying that is it easy to implement cm_add_library so you can handle the above case (the vararg case) but you can also handle the case where the user does: cm_add_library( "simpleLib", "STATIC", sources) In this case, cm_add_library receives 2 string arguments and 1 table argument. The implementation of cm_add_library can be easily written to handle both cases so the CMake scripter can write whatever seems most natural to them. This makes the need for unpack() unnecessary. > Yes I know. I was saying that passing "file1.c file2.c file3.c" is > not a solution to Lua's excessive quoting problem, because you'd be > sacrificing desireable processing capabilities. We want to be able to > operate on lists/tables of stuff with FOREACH, LIST, individuated > parameters, and so forth. I'm not understanding what you're getting at. But I think this is probably much ado about nothing. Once you get your files into a table, you can do all your expected foreach/list stuff. There won't be any excessive quoting here. I don't see any reason while the CMake FOREACH couldn't also be exposed through a Lua API either so you should be able to use which ever fits best. > > The point is that the marketing luster of Lua will fade. The legacy > CMake builds will all be using an old, hoary version of Lua. CMake > will have to support those old builds to some degree. It won't be > able to utilize newfangled Lua stuff, if the newfangled stuff breaks > backwards compatibility. I bet there are problems between Python > 1.5.2 and 2.5.1, although I'm not up on them. I bet the Python > community doesn't consider Python 1.5.2 a sales point, if they stare > closely at SCons. Now, people may not stare closely. And in any > event, the luster of Lua will probably last 5 years. But then it'll > be over, and the real question will be, was it a cool choice for text > processing? 'Cuz that's what a build system mostly is. > > What we really want is Ruby without the licensing hassles. And a bit > faster. Well, not really. Embedding Ruby (or Python) is a lot harder than embedding Lua. There are very few languages that focus specifically on this niche. Most languages want to be the end-all and offer great libraries to easily build certain types of things (Rails, Twisted). Lua's focus is embedding which is why it is a great tool for this specific kind of job with regards to CMake. As far as Ruby syntax is concerned, I don't see how it is significantly different than Lua. All the Ruby code I've seen also has quotes around string literals and commas separating items in lists. But I wouldn't worry much about the speed of Ruby. Most of the performance bottlenecks will be within CMake itself doing the heavy lifting and file I/O. It's just nice that with Lua, you don't have to fend off detractors on the speed argument so much. But I don't see it as a real problem. As for marketing, I can't predict the future. Any language is subject to these whims. We could all be writing in Lisp some day. However, Lua has been around for awhile (it's older than Java) and I don't expect it to disappear. And adoption of Lua has been driven more by the fact that it's a really good tool for solving specific sets of problems, not so much marketing. (It's just interesting that World of Warcraft has suddenly changed the marketing aspect because the game is so huge.) I can say with some certainty that even if the marketing loses its luster, it will still be an easier sale than marketing CMake's proprietary language. > > cm_add_library( "simpleLib", STATIC, sources) > > That's an improvement. > > I wish we could get rid of quotes in places that don't need them. How > easy would it be to modify Lua in that regard? So, CMake would be a > Lua variant rather than straight Lua. > cm_add_library( "simpleLib", STATIC, sources) So, as I said, there are some tokenizer/macro preproecessor things available that are intended to help people create more domain specific languages that work on top of Lua. But I am not terribly familiar with them. I do know one of them was written by LHF, one of the Lua authors. Maybe this is it? http://lua-users.org/lists/lua-l/2006-09/msg00282.html One thing to be aware of though. Notice strings are quotes, but variables are not (like C/C++). So an ambiguity problem may be created. So if I were to do something like: myLibraryName = "simpleLib" listOfFilesFound = cm_file(GLOB, "*.c") -- wrapper around CMake FILE, but utilizes return parameter cm_add_library(myLibraryName, STATIC, listOfFilesFound) Notice that all the quotes are gone by the cm_add_library command because everything was somehow placed into a variable. _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake