Re: [CMake] CMake and Lua
On Saturday 01 March 2008, Miguel A. Figueroa-Villanueva wrote: On Fri, Feb 29, 2008 at 11:09 AM, Bill Hoffman wrote: Rodolfo Schulz de Lima wrote: The main issue with CMake script isn't when writing a build script, but when writing auxiliary stuff, like a more elaborate Find*.cmake. Just look at FindwxWidgets.cmake to see what I mean... Thanks for the feedback. I am wondering if there is something that can be done in CMake c++ code to make writing a Find module like wx widgets easier. Maybe regular expressions in the find_* commands would help. Lots of the verbosity comes from finding different names for libraries and paths. I think that has come up on the list or the bug tracker recently. The new break and return could clean it up some more, and the use of lower case would make it look nicer. -Bill quote from another related thread On Fri, Feb 29, 2008 at 1:22 PM, Rodolfo Schulz de Lima wrote: Bill Hoffman escreveu: Enjoy! Wow, that must be a world record... I've mentioned the problem at 10:57 Don't think so, there are 4 hours in between, Bill and/or Brad have already proven before that they can be even faster than that :-) (Brazilian Standard Time), and the solution got committed at 14:18 (BRST). Guinness anyone?? I which my cable TV customer support were that fast...thanks a lot Bill. And you all thought Bill was so resistant to change :P I really think this is the stuff that needs to be addressed and obviously Bill and the rest of the CMake developers are very willing to accomodate this. That is, things like relaxing the if/else constructs, scoping, return, break, lowercase commands, etc. are the components we need to help facilitate writing more complex stuff in CMake scripting. Yes, maybe we should now simply wait a bit and see how new cmake scripts with the new features actually look. What we all know are cmake scripts using cmake 2.2/2.4 syntax, cmake cvs has all the mentioned improvements, maybe these are already enough to make the scripts easier to read/write and more scalable (e.g. scoped vars and functions). Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Mar 3, 2008 at 6:13 PM, James Mansion [EMAIL PROTECTED] wrote: Brandon Van Every wrote: 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. Fine. Don't use his code. I try to avoid automake. Don't you see the problem as far as fragmenting open source builds in general? In the current day, avoiding automake is not a realistic answer as far as the vast majority of open source developers are concerned. If you are personally converting every single open source package out there from automake to CMake, that's commendable, but it's not a labor we should expect the open source world to habitually undertake. If you are not converting anything at all, and simply avoiding vast tracts of the open source landscape, then you are not taking into account the concerns of a very large audience. CMake cares about that audience and it's part of why the Tower Of Babel approach is deemed unacceptable. Other projects, like SCons, do deem it acceptable; you are certainly free to use those instead. I've reported on a number of alternate tools as of late, and given the state of the competition, I do think that CMake's desire to be 1 standard rather than many standards is reasonable. 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. The two are not separable. The end user is a customer for *all* of the developer's product. If its a real issue, the developer will change. So first I implement my CMake build in TCL. Then people scream at me. I re-implement my build in Ruby. People scream at me again, especially the Python crowd. So I add a Python build and chug with both Python and Ruby for awhile, but I'm noticing it's a headache to bother supporting both. I'm getting really sophisticated with SWIG and every single scripting language out there, so I dump everything and build with Lua, for my own sanity of maintenance. People scream again because it isn't their personal favorite language. By this point, I've spent so much time futzing with the build system, that I haven't really developed a product that people care about. I give up and swear off of the never-ending open source money pit for good. I get a real job shoveling Ant. I hate it but I get paid well. That's how I see it going down in the real world. Most open source projects don't have the luxury of change, change, change. You're also making the unwarranted assumption that the developer is 1 person. Open source projects are often polyglot. People war over these issues. It causes enormous friction that keeps anything from getting done. The biggest problem with verbosity is that its not really possible to do subroutines, Actually it is, even in CMake 2.4.8. The price is you have to write these horribly long global variable names, so that your macro subroutines won't collide with higher level macros. I've written half of a general purpose Autoconf + GMake -- CMake translator using nothing more than macro subroutines and regular expressions. Some people call that an extreme abuse of CMake script. I say it worked, and the macros were only 3 layers deep. But that was deep enough to clamor for scope and functions, and we're getting it in CMake 2.6.0. As far as I'm concerned, this kind of verbosity has been addressed. I'm probably on the high end of the absurdity scale for what I've pushed CMake script to do, and I did get through it even with what's available now. I pushed CMake script that hard (1) to get paid to push the limits of CMake script, to find out what really needed to be improved about it in the worst case, and (2) the hope that by providing a large example of CMake script doing something non-trivial, I might help spawn more CMake script gurus. (1) worked, jury's out on (2). and the keywords-as-functions just look wrong to me. But if you have a reason to write enough of it, you quickly get over it. People often must have forced reasons to deal with something new and different. If your boss says, I want a pilot build written in CMake 1 week from today. We have to know if it's capable of solving our problems, then you just go do it. If your boss says, Well what do you think about this-or-that build tool? you have the wiggle room to complain and carp about whatever you like, and thereby defeat the use of the tool. If you don't have any boss, if you're just trying things out, you have no deadlines at all and you can reject stuff on any basis you like. It all depends on what you
Re: [CMake] CMake and Lua
Bill Hoffman wrote: James Mansion wrote: So, C++ is the language we picked/like. You are welcome to contribute one in C++. Imagine if you could develop generators (I assume that is what you mean by emitters) in any language! You wouldn't even be able to share them. Bill, I like C++ as much as anyone, but I also work in other languages. What youu wrote above is such utter bullshit that its hard to credit. If I have a project that is largely in a more convenient language - whether Java or Python or C# (or even Lua) - and it has material components in C++ for performance or reuse reasons, then it is clearly reasonable to ship something that can make a good stab at building the DLLs and running SWIG (and I think CMake reasonably can do this) *and* to expect the target user base to have the runtime for the other language concerned. You are inventing this paranoid fantasy of a 'tower of babel' effect poisoning the centrally maintained CMake. And that's just not justified. 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. If you did use an arbitrary language bound to CMake core, people building your project would have to build/get something different than potentially any other CMake based project. So? Is that a problem in *every* context? 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? I like CMake. But the language is impenetrable, verbose, and basically poor - it can't quite decide whether to declaratve/functional or imperative, has limited data type or structure support - or modularity or reuse support. 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 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. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
James Mansion wrote: Bill Hoffman wrote: James Mansion wrote: So, C++ is the language we picked/like. You are welcome to contribute one in C++. Imagine if you could develop generators (I assume that is what you mean by emitters) in any language! You wouldn't even be able to share them. Bill, I like C++ as much as anyone, but I also work in other languages. What youu wrote above is such utter bullshit that its hard to credit. Wow this thread is really getting out of hand! Please refrain from swearing If I have a project that is largely in a more convenient language - whether Java or Python or C# (or even Lua) - and it has material components in C++ for performance or reuse reasons, then it is clearly reasonable to ship something that can make a good stab at building the DLLs and running SWIG (and I think CMake reasonably can do this) *and* to expect the target user base to have the runtime for the other language concerned. You are inventing this paranoid fantasy of a 'tower of babel' effect poisoning the centrally maintained CMake. And that's just not justified. I don't agree, having multiple language bindings for CMake would be a mistake. As I have said perhaps two languages someday. But no more than that. . If you did use an arbitrary language bound to CMake core, people building your project would have to build/get something different than potentially any other CMake based project. So? Is that a problem in *every* context? Overall, I think it would be bad. 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 they only use the Ruby, and Python for the build system parts. What if people want to share build system stuff wrapped in different languages. I like CMake. But the language is impenetrable, verbose, and basically poor - it can't quite decide whether to declaratve/functional or imperative, has limited data type or structure support - or modularity or reuse support. 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 don't think I have to say Enough. It has evolved, and built some pretty impressive stuff. I am not completely happy with it, but it works. I also don't think dropping support for it is an option. 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. OK, now you are talking about one language again. I was trying to say that having a swig like any language support was bad. I am also saying that we will support the current language as long as there is a CMake. We may or may not add Lua. But, I don't think we will be providing a swig style java, c#, Lua, python, tcl language binding to the CMake make generation system. I also feel pretty confident that the core generation system will stay in C++. So, a summary seems in order in hopes of getting this discussion back on track. 1. CMake may add support for an additional language. Right now Lua seems to be the best candidate for that. It is small and easy to embed. The Lua stuff would have to work well/exist with the current CMake language. I am still not convinced about this, but it is an option. 2. It does not make sense to use SWIG to open up bindings to any arbitrary language for CMake. There should be one binary the CMake users can download/install to build any project that uses CMake as a build system. It should not depend on any outside stuff. It should require a C/C++ compiler to build. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
At 3/2/2008 09:10 AM, James Mansion, wrote: If I have a project that is largely in a more convenient language - whether Java or Python or C# (or even Lua) - and it has material components in C++ for performance or reuse reasons, then it is clearly reasonable to ship something that can make a good stab at building the DLLs and running SWIG (and I think CMake reasonably can do this) *and* to expect the target user base to have the runtime for the other language concerned. *Your* target user base. You focused here on your problem, which is a specific scenario, whereas we, at Kitware, have to think about a larger picture, and that includes making the majority of people using CMake happy, as well as make sure the time and/or money they invested over the past 5/7 years doesn't go down the drain. The line has to be drawn somewhere and CMake is a build system, not a language; the problem of dependencies has been debated more than a few times, and it is not just a matter of asking hey, please add my favorite language to the mix, it rocks. 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 - Then probably that is because they don't. etc. You can go either way. 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!'. [...] Or you can just sit down, get it done, and move on because it's not that complicated after all. Please consider that people haven't waited for you to build complex and ambitious projects for years, where writing CMake scripts sometimes seemed like vacation in comparison. The KDE project recently switched over to CMake without anybody jumping off a German bridge. It has been done, it's being done, and it's working mostly fine. It's not a beauty pageant contest, it's getting software to build; ultimately, as much as you can marvel at your carefully crafted lines of autoconf or CMake, what matters is what said software is going to do, being high-end scientific visualization, medical imaging or surfing the web, and in that regards CMake has enabled a lot of people to get that software up and running in less time/money, directing resources to what matters, the software itself. The long term choices we are making, the decision Bill is talking about, are meant to prevent this build process to become impossible to learn and/or maintain. If you are saying that compatibility with the naivety of the past No, it is said because people are running businesses, don't grow money trees and have no personal access to time machines. A huge number of lines of CMake have been written already, and not just by us of course. Backward compatibility and maintenance are extremely important. That's why that suggestion to force a switch to LUA is non-sense. That's why maintaining two or more languages, to my opinion, will only provide more headaches to people who want to get their software to build and focus on the software, in scenarios that may involve complex code and a lot of people participating. This is not building for the sake of building. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
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
RE: [CMake] CMake and Lua = DSL!?
Hello everyone, Sorry for the quick interruption, but somehow I have the feeling this discussion will start again and again and again, if it has ever appeared to end. Here are my two cents... IMHO there might be a misunderstanding concerning Kitware's CMake strategy: It is a domain specific language (DSL) for -- as this might indicate -- one specific purpose and therefore, by intention, not a general purpose (scripting) language; thus it concentrates correctly on its (single powerful) core task/challenge. An estimated set of 7% of CMake's language commands covers about 97% of the usual cases. (Note that I have not even thought about thinking about this numbers.) Please accept this as an almost completely serious feed to a never ending (?) discussion, Reinhold ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake and Lua = DSL!?
On Sun, Mar 2, 2008 at 2:30 PM, Reinhold [EMAIL PROTECTED] wrote: Hello everyone, Sorry for the quick interruption, but somehow I have the feeling this discussion will start again and again and again, if it has ever appeared to end. Here are my two cents... IMHO there might be a misunderstanding concerning Kitware's CMake strategy: It is a domain specific language (DSL) for -- as this might indicate -- one specific purpose and therefore, by intention, not a general purpose (scripting) language; thus it concentrates correctly on its (single powerful) core task/challenge. An estimated set of 7% of CMake's language commands covers about 97% of the usual cases. (Note that I have not even thought about thinking about this numbers.) Please accept this as an almost completely serious feed to a never ending (?) discussion, When I say the technical merit of Python, Ruby, or Lua over CMake script has not been demonstrated, it is speaking to this very point. Perhaps general purpose scripting *is* provably better for a large scale build, but I would like to see a large scale project that proves that, rather than assuming it. From a marketing and documentation standpoint, standard scripting languages are provably better than DSLs. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Bill Hoffman wrote: So what exactly about the CMake language gives you this feel? That would be: 1) the syntax and 2) the modularity constructs I know its 'only' scripting to manage declarations into the engine. Its a shame you can't write emitters except in C++ but that certainly wouldn't be something I'd want to try with a language like this. But if we did that would we have a binary that that had all the wrapped languages? Why? I don't care what you ship in the CMake core library. I just want to be able to do any coding in my project in a manner that's comfortable. Even if the result is mixed, a few lines in site config should enable the engine to find the interpreter DLLs and integrate them. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
James Mansion wrote: Bill Hoffman wrote: So what exactly about the CMake language gives you this feel? That would be: 1) the syntax and 2) the modularity constructs I know its 'only' scripting to manage declarations into the engine. Its a shame you can't write emitters except in C++ but that certainly wouldn't So, C++ is the language we picked/like. You are welcome to contribute one in C++. Imagine if you could develop generators (I assume that is what you mean by emitters) in any language! You wouldn't even be able to share them. be something I'd want to try with a language like this. But if we did that would we have a binary that that had all the wrapped languages? Why? I don't care what you ship in the CMake core library. I just want to be able to do any coding in my project in a manner that's comfortable. Well, I suppose you don't have to use CMake. Perhaps scons would be a better fit for your tastes. If you did use an arbitrary language bound to CMake core, people building your project would have to build/get something different than potentially any other CMake based project. Even if the result is mixed, a few lines in site config should enable the engine to find the interpreter DLLs and integrate them. I guess you would provide the cross platform versions of the dll's that people would need. I know it is your project. But on a larger scale this type of thing would be bad for CMake. Lets say you are developing an open source project. I am a user that finds your project. Hey, they use CMake, I know how to use CMake, I even already have it installed for my platform it is working great. Hey, this project does not build it needs ruby CMake, I don't have Ruby CMake. Even worst lets say I want to combine to projects and one picked Ruby CMake, and one picked Python CMake, and another Tcl CMake. 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. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake and Lua
On Fri, Feb 29, 2008 at 12:59 AM, Sebastien BARRE [EMAIL PROTECTED] wrote: Brandon wrote: I'm willing to give Bill some time to think about the undoability of CMake -- Lua translation Great. And by some time you mean someday, therefore 2 years, right. Your style of communication is counter-productive. Here is where a notion of 2 years fits into a sequence of events: 1) Kitware contemplates the wisdom of adding Lua support. 2) Kitware commits to Lua support. 3) Kitware officially releases Lua support, proving their commitment is real. 4) Brandon and/or others attempt to build CMake -- Lua translators. 5) Brandon succeeds in writing a perfect CMake -- Lua translator and contributes the source. 6) Kitware officially releases and supports the translator 7) 2 years later, Kitware adopts you must translate to Lua as official policy. We're still at (1). I'm willing to drop discussion of CMake -- Lua translators for 3 months, to give Bill time to think. *If* I don't hear defeatism on the subject. For instance, the mood a few months ago was Kitware can't support 2 languages. At that time, I proposed automatic language translation because that way, you don't have to support 2 languages indefinitely. I'm pleased that nowadays, Bill thinks that Kitware can in fact support 2 languages indefinitely. I just see it as unnecessary. Especially in open source, I think it is reasonable to make developers do trivial amounts of work to move on, at some point, if the migration tools have been thoroughly tested and proven in the field. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Sat, Mar 1, 2008 at 7:08 PM, Brandon Van Every [EMAIL PROTECTED] wrote: Especially in open source, I think it is reasonable to make developers do trivial amounts of work to move on, at some point, if the migration tools have been thoroughly tested and proven in the field. I did just realize one gotcha however that I hadn't previously considered. *Which* version of CMake would be translated? Writing a translator for 1 or even a few recent versions of CMake is one thing. Trying to be bug-for-bug compatible over the entire history of CMake's development is quite another. There would have to be some cutoff point, where if you want compatibility with a really ancient version of CMake, you have to just use an old version of CMake, and not expect new features or ongoing development. Then again, if translation was proven for CMake 2.4.x forwards, for a goodly number of years, and officially supported, then it could pave the way for translation efforts even farther back into CMake's history. Say, for instance, 80% of the builds out there are translatable because they're sufficiently modern. 20% aren't, and it takes a much longer time to make them translatable. So, it may still be possible, but 2 years wouldn't be long enough to force migrations. More like 5..10 years. On that timescale, it's not that different from supporting 2 languages indefinitely. Even if the support can indeed be terminated in 10 years, it's a lot of time to be splitting the community with 2 languages. It really all depends on how far back the CMake compatibility has to go. A far more likely scenario is, CMake -- Lua translators are used to get 99% of the CMake community onto Lua. The remaining 1% contract with Kitware for their special needs. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Brandon Van Every wrote: We're still at (1). I'm willing to drop discussion of CMake -- Lua translators for 3 months, to give Bill time to think. *If* I don't It really all depends on how far back the CMake compatibility has to go. A far more likely scenario is, CMake -- Lua translators are used to get 99% of the CMake community onto Lua. The remaining 1% contract with Kitware for their special needs. Rats, I thought I had three months before you brought up translators again This is a very good point (old versions of CMake). I am sure there are other issues we are missing. Uses and mis-uses of CMake. However, arguing about a hypothetical translator is a waste of time. The amount of code in cmake that supports the current language is small, and I see no reason to keep it, even if there is another language. So, I am asking nicely please stop this thread on translators. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
James Mansion wrote: Sebastien BARRE wrote: Again: *deal*. February 29th, 2010 *precisely*. Special CMake/Lua day, the 29th. That will indeed be a very special day. Shame really. I like Lua, and I find that the CMake script language seems designed to make COBOL coders feel they don't actually have the worst job in the world. So what exactly about the CMake language gives you this feel? And a SWIG based wrapping of the C++ code would surely allow extension of the core in 'soft' languages too, so that generators could be develeoped and so on too. But if we did that would we have a binary that that had all the wrapped languages? CMake is meant to be a build tool, and not a toolkit library. There are already adoption issues because you have to install CMake before you can do a build. Imagine how much worst it would be if you had to pick the right language variant of CMake before you could build a package using CMake. I love SWIG and language wrapping and it makes sense for a library of visualization or computer vision tools. However, in the case of a build system it would be a tower of babel. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Brandon Van Every wrote: Only thing problematic I could see, is if someone's getting clever and using CMake script to generate CMake script. I think it would be reasonable to make such people untangle their metaprogramming. That's crazy, no one would do something like that... But even if they did, I would not want to invalidate there effort by obsoleting the language they programmed in. It would be much safer and easier to continue to support it in the core of CMake. It's 2x work to support CMake script and Lua indefinitely. Actually, I don't agree with you here, and it would be me and the CMake team maintaining it and not you. I believe backwards compatibility is key to adoption of software. For a good read see here: http://www.joelonsoftware.com/articles/APIWar.html See the part about how the DOS game SimCity had a bug, and Microsoft worked around that bug. If something does not build with CMake, then CMake will get blamed. If a translator fails CMake will get blamed. I just don't believe that translation can work, and the fun part is that it can't even be proved that the translator works 100% of the time... That's not a realistic concern though. You will either decide to move on to Lua or you won't. Any amount of excuses can be invented if you aren't willing. It is a valid concern but has nothing to do with the using Lua or not. Translators don't work for 100% of the cases, that is a fact! You of all people should realize that. However, supporting both languages is an option. Also, please refrain from calling me a liar. I am being very honest in my discussion here. There are no hidden motives or invented excuses. You may not agree with me, but that does not mean I am inventing excuses. If this is how you treated the Chicken maintainer, he may have dropped CMake just to get you off his mailing list I just got back from talking about CMake at FOSDEM, and was very pleased with the reception CMake is getting in the European open source community. Many folks are using it, and like it. No one complained about the language. One person asked about Lua, and was mildly interested but could talk it or leave it. I told him we were still evaluating the option and we are. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Brandon Van Every wrote: That's contradictory. You don't bog yourself down with enormous support burdens for some teeny weeny percentage of people who do something really weird. Software *is* invalidation of effort. Stuff gets written, stuff gets changed, stuff gets maintained. I don't think it is an enormous effort to maintain what we already have. I think it is an enormous effort to write a translator. I think translators don't work. It is one thing to convert a word document from one version to another. It is a totally different thing to translate a human written computer language from one to another and have it work. I haven't called you a liar. It is true that I've said you're making excuses. It could have a bug! It won't be 100%! Something could go wrong! Someone could blame us! That's the order of the day in You are missing my point. I think we should respect the people that have picked CMake to build there project, and part of that respect includes not obsoleting there hard work. We are disagreeing on this point because of the first point. You believe that a good enough translator is possible. I do not. Just suppose I am correct and it is not possible to write a good enough translator. Would you then still advocate dropping the cmake language? I am not coming up with excuses here, I really really do believe that the translator idea is nonsense. How many times do I need to type it for you to understand that is what I believe? I'm willing to call a spade a spade. I'm also willing to confront people when I have a problem with them. If that breaks the relationship, that does not trouble me. Better than giving lots of free work to someone who isn't really using it. You are not willing to accept that I have a different point of view. A good enough translator is not possible. That is my position. I am not talking about corner cases here. I am thinking of real world projects like KDE/ParaView/SecondLife/VTK. The thought of translating these large projects with a translator is not one I would appreciate being driven into by the CMake developers. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Thu, Feb 28, 2008 at 4:08 PM, Bill Hoffman [EMAIL PROTECTED] wrote: I think it is an enormous effort to write a translator. I think translators don't work. It is one thing to convert a word document from one version to another. It is a totally different thing to translate a human written computer language from one to another and have it work. CMake script, by design, is a trivial language. If you actually do implement Lua at some point, then I'll look at CMake -- Lua translation, if it makes business sense for me to do so. I believe other people in the Lua community will also. There are a lot of language translator and metaprogrammer guys over there. They abound in the Lua community because Lua was intended to be an embeddable basis for Domain Specific Languages. Their perspective, and mine, is that CMake -- Lua translation is a pretty easy problem. I mean, the entire syntax of CMake is command(arg arg KEYWORD arg arg ...), what's the big deal? You are missing my point. I think we should respect the people that have picked CMake to build there project, and part of that respect includes not obsoleting there hard work. We are disagreeing on this point because of the first point. You believe that a good enough translator is possible. I do not. I believe an *almost perfect* translator is possible. As perfect as open source software ever is. In fact, given CMake's trivial syntax, I can't think of any reason why it wouldn't be. Can you give me one concrete example of something that would actually be hard? I gave you the only one I could think of: metaprogramming. Almost nobody metaprograms CMake. It's not a corner case worth worrying about. Give me an example of something that people do in the real world with CMake script that would be hard to translate to Lua. Just suppose I am correct and it is not possible to write a good enough translator. Would you then still advocate dropping the cmake language? Of course not. That's why I said the translator would have to prove itself for 2 years. I am not coming up with excuses here, I really really do believe that the translator idea is nonsense. How many times do I need to type it for you to understand that is what I believe? Ok, at this point, I intellectually understand what you believe. You haven't provided much evidence for your belief so far. You've commented that general purpose language translation, such as Fortran to C, is exceedingly difficult. That is true, but we're talking about converting CMake script, a trivial language. You haven't provided an example of something that would be difficult to translate. You agreed that nobody metaprograms CMake script, that that's crazy talk. You are not willing to accept that I have a different point of view. A good enough translator is not possible. You have provided no firm evidence for your point of view, so I will continue to challenge it. That is my position. I am not talking about corner cases here. I am thinking of real world projects like KDE/ParaView/SecondLife/VTK. The thought of translating these large projects with a translator is not one I would appreciate being driven into by the CMake developers. Estimating conservatively, I got 1/2 of the way there with Mozilla. Autoconf + GMake -- CMake is a much more difficult translation problem than CMake -- Lua. I know what is possible. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Thu, Feb 28, 2008 at 5:54 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Just suppose I am correct and it is not possible to write a good enough translator. Would you then still advocate dropping the cmake language? Of course not. That's why I said the translator would have to prove itself for 2 years. So, I guess I will wait until then, and you can prove me wrong... Until then, can you give it a break? Sure. Long as you realize that not everybody shares your pessimism about translators, and that if you do implement Lua support, people will attempt it. Actually I pointed out that you did metaprogram in CMake (in a sarcastic way). Actually, if metaprogramming means generating CMake script dynamically and then executing it, I didn't do that. I just used CMake script as the implementation language for my translator. It could be translated to Lua no problemo. It would still only be an Autoconf + GMake -- CMake translator. I just don't have the time to think about it. I've had 6 months of active work to think about it. Here is one case you have not considered. There exist some IDE projects that generate CMake code like KDevelop. The translator would not help them at all as the CMake code is embedded in C++ or java. There exist cmake code generators. I guess you would say generate, then translate? Sounds like a mess. If CMake went to Lua, presumably these IDEs would want to do the same things in Lua. If not, if the IDE developers don't have energy to bother, then that's an example of 2 languages splitting the community. That's why I think it's important to establish Lua as the primary language, if it is to be done at all. Automatic translation is essential to making Lua primary, otherwise people simply won't do it. You are not willing to accept that I have a different point of view. A good enough translator is not possible. You have provided no firm evidence for your point of view, so I will continue to challenge it. You have provided no evidence that such a thing is possible. Other than you claim that it will be simple. I've written 1/2 of a translator for a much harder problem. There's no conceptual barrier to completing the work, it's only a matter of people's will. Mozilla was just too big a guinea pig for me to finish within the bounds of the contract. No I haven't provided strict evidence of CMake -- Lua translatability, but I've proven the viability of large scale translation in general, even using extremely crude methods. The primary barriers I see to actually realizing a translator are (1) what technical basis should it have? regexes are not ideal. Some in the Lua crowd talk about Lua PEGs. (2) Show me the money. It's a lot of work to provide a 100% translator. I have never seen a perfect translation from one language to another. Can you give me an example of one that exists? I will put it on the backburner as something to inquire about. BTW, You have no idea if you were 1/2 there or not, because you quit. I did not quit. Rather, the contract terminated. I have a pretty solid idea of how much more work needed to be done. You might only be 10% of the way there. The last 10% often takes 90% of the time with software projects. Unless you finish the mozilla translator and build mozilla we will never know. CMake script -- Lua is merely a mapping of syntax. Nothing more. When the contract ended, I had a 95% translation of Mozilla's huge monolithic configure.in to CMakeLists.txt syntax. Semantics are another matter. In the case of Mozilla, a lot more semantic work remained to be done. Autoconf + GMake do not have exactly the same semantic model as CMake. So yes, I cannot be certain how much longer the Mozilla translation really would have taken, but conservatively I estimated I was 1/2 there. I actually believe I was 2/3 there, but as you say, unless someone else picks up the work or decides to pay me to continue, we'll never know. This is irrelevant to the simple problem of translating CMake script syntax to Lua syntax. I don't think you can show me any irreconcilable semantic difference between CMake script and Lua. Given that, in principle, perfect translation is possible. In practice, someone has to do it and it's a lot of work. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
At 2/28/2008 09:06 PM, Brandon Van Every wrote: So, I guess I will wait until then, and you can prove me wrong... Until then, can you give it a break? Sure. Long as you realize that not everybody shares your pessimism about translators, and that if you do implement Lua support, people will attempt it. You've got a deal. I'll make sure to swing by Bill's office tomorrow and remind him about his realization. Let me write that down. On a post-it or something. 2 years break, that's a bargain Bill. If CMake went to Lua, presumably these IDEs would want to do the same things in Lua. That's indeed obvious, these IDEs would absolutely switch to LUA too. Do they have a mailing list? My gut feeling is that they would want to hear about it. Like now. I've written 1/2 of a translator for a much harder problem. [...] but I've proven the viability of large scale translation in general, even using extremely crude methods. And by proving it you mean it was never adopted or even finished, and it is actually not translating anything that can build Mozilla. Because if that's the case, I prove it too. It's made of air. I stock it in a jar, but it's at the bottom of a river at the moment. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Thu, Feb 28, 2008 at 11:41 PM, Sebastien BARRE [EMAIL PROTECTED] wrote: At 2/28/2008 09:06 PM, Brandon Van Every wrote: So, I guess I will wait until then, and you can prove me wrong... Until then, can you give it a break? Sure. Long as you realize that not everybody shares your pessimism about translators, and that if you do implement Lua support, people will attempt it. You've got a deal. I'll make sure to swing by Bill's office tomorrow and remind him about his realization. Let me write that down. On a post-it or something. 2 years break, that's a bargain Bill. On that note, be sure to include actually implementing Lua. If CMake went to Lua, presumably these IDEs would want to do the same things in Lua. That's indeed obvious, these IDEs would absolutely switch to LUA too. Do they have a mailing list? My gut feeling is that they would want to hear about it. Like now. If you are pro-Lua then you can certainly make them aware. I've written 1/2 of a translator for a much harder problem. [...] but I've proven the viability of large scale translation in general, even using extremely crude methods. And by proving it you mean it was never adopted or even finished, and it is actually not translating anything that can build Mozilla. Because if that's the case, I prove it too. It's made of air. I stock it in a jar, but it's at the bottom of a river at the moment. It's one thing to throw stones. It's another thing to actually attempt it, and get pretty far to making it work. Finish schminish. I finished Chicken Scheme's build, to a professional level, and it got thrown out anyways. People either want to make something happen or they don't. There is no technical barrier to this, only a labor barrier. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
At 2/29/2008 12:03 AM, Brandon Van Every wrote: You've got a deal. I'll make sure to swing by Bill's office tomorrow and remind him about his realization. Let me write that down. On a post-it or something. 2 years break, that's a bargain Bill. On that note, be sure to include actually implementing Lua. Again: *deal*. February 29th, 2010 *precisely*. Special CMake/Lua day, the 29th. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Fri, Feb 29, 2008 at 12:11 AM, Sebastien BARRE [EMAIL PROTECTED] wrote: At 2/29/2008 12:03 AM, Brandon Van Every wrote: You've got a deal. I'll make sure to swing by Bill's office tomorrow and remind him about his realization. Let me write that down. On a post-it or something. 2 years break, that's a bargain Bill. On that note, be sure to include actually implementing Lua. Again: *deal*. February 29th, 2010 *precisely*. Special CMake/Lua day, the 29th. Or No Deal. 2 years is a number you've inappropriately reused from an unrelated context. I'm willing to give Bill some time to think about the undoability of CMake -- Lua translation. Over time, his position has moderated on Lua itself, so perhaps the same will happen with regards to translation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Sebastien BARRE wrote: Again: *deal*. February 29th, 2010 *precisely*. Special CMake/Lua day, the 29th. That will indeed be a very special day. Shame really. I like Lua, and I find that the CMake script language seems designed to make COBOL coders feel they don't actually have the worst job in the world. And a SWIG based wrapping of the C++ code would surely allow extension of the core in 'soft' languages too, so that generators could be develeoped and so on too. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
At 2/29/2008 12:39 AM, Brandon Van Every wrote: Again: *deal*. February 29th, 2010 *precisely*. Special CMake/Lua day, the 29th. Or No Deal. 2 years is a number you've inappropriately reused from an unrelated context. You are right, I apologize. Bill said: we might have two official languages someday then a guy, let's just name him B.V.E, took someday, a magic eight ball, and probably a raccoon to extrapolate right away: I think if the automated translation tool had proven itself for a couple of years, it would be perfectly reasonable to force people to move on (to LUA). So there is still that 2 year window [...] Now it is true, I went a little too far by translating a couple of years to 2 years. It obviously meant, a couple, as, you know, a loving relationship of years. That was inappropriate, and probably illegal in many American states. I'm willing to give Bill some time to think about the undoability of CMake -- Lua translation Great. And by some time you mean someday, therefore 2 years, right. The time the automated translation had proven to work. Now you just need to prove it. OK, sorry, prove it *again*. I don't want to waste your time anymore, time that could be spent proving away. Cheers ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
James Mansion wrote:
Ken Martin wrote:
other's variables out of the box. But with the Modules directory we either have to
have a copy of each module for every possible scripting language, on the fly
converters between any two scripting languages, or something like that to make it
work. Trying to figure out how to manage the mixed
Surely the idea is that modules should be self contained: they expose data by
registering it into the CMake core (possibly with callbacks) and interface to other
modules through the core. Modules can be in different languages without the issue you
indicate (or, the modularity is poor and the binding too tight).
Yes, this is the idea. All bindings only call C++ functions of
CMakeCore, by this we only have a n-to-one problem.
And it looks like most stuff is to pass and parse long
const char* strings, a lists with separator ;.
For instance see the SET command in cmSetCommand.cxx:
// add the definition
this-Makefile-AddDefinition(variable, value.c_str());
The problem is how to handle SET(X ${Y} z). ${Y} is a list
for cmake script but only a string for other languages.
My first idea is to introduce a list class on the C++ side,
but I assume there are already myriads of solutions to
represents lists in C++, not only std::list.
Peter
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
If people want a tower of babel set of languages that can drive CMake, they can do it now. Just write most of your build system in X, tell your users they have to install CMake and X. Then use the powerful language X to generate simple CMake files. (where X is python, tcl, perl, lua, or what ever someone likes.) For the most part the actual build part of CMake is pretty simple: add_library(foo ...) add_executable(bar ...) target_link_libraries(bar foo) Even find modules could be written in Lua or some other language then called with execute_process. The trick is the people that are building that package will need CMake and X. The original intent of having CMake create it's own language was to have minimal dependencies on CMake itself. To build CMake, you need a C++ compiler and its native build tools. Since CMake was developed to build C++ programs, this seemed like a good dependency. Having to install CMake on the system you want to build on is often a show stopper for people looking at CMake compared to autotools. Having to install CMake, and X, Y, or maybe Z would be even worst. Lua is interesting since it is small and easy to embed. I am still not sure it is worth the effort. However, the idea of having multiple languages is IMO horrible. Unless all of those languages are built in and delivered with the one CMake binary it will turn CMake projects that use these extra languages into a pain in the neck to build. You will have what I like to call the easter egg hunt to build packages. Users will have to install several packages just to build one package. Also, backwards compatibility is something we take very seriously. If someone picks CMake as a build tool, we have to respect that choice and try our best not to break that project. There are very large projects that have many lines of CMake code in them. People have put a great deal of effort into creating those files. If they don't have the time to re-write in a new language, I don't blame them. I also won't try to force them to do it, by obsoleting the current language. So, we might have two official languages someday, but no more than that. If you want to use other languages, then use execute_process inside your CMake files, and make sure to tell your uses what they have to install to build your package. -Bill -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Wed, Feb 27, 2008 at 4:34 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Also, backwards compatibility is something we take very seriously. If someone picks CMake as a build tool, we have to respect that choice and try our best not to break that project. There are very large projects that have many lines of CMake code in them. People have put a great deal of effort into creating those files. If they don't have the time to re-write in a new language, I don't blame them. This is why I think an automated translation tool, say from CMake script -- Lua, is essential to a migration strategy. I also won't try to force them to do it, by obsoleting the current language. I think if the automated translation tool had proven itself for a couple of years, it would be perfectly reasonable to force people to move on. So there is still that 2 year window of supporting 2 languages. So, we might have two official languages someday, but no more than that. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Brandon Van Every wrote: On Wed, Feb 27, 2008 at 4:34 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Also, backwards compatibility is something we take very seriously. If someone picks CMake as a build tool, we have to respect that choice and try our best not to break that project. There are very large projects that have many lines of CMake code in them. People have put a great deal of effort into creating those files. If they don't have the time to re-write in a new language, I don't blame them. This is why I think an automated translation tool, say from CMake script -- Lua, is essential to a migration strategy. I also won't try to force them to do it, by obsoleting the current language. I think if the automated translation tool had proven itself for a couple of years, it would be perfectly reasonable to force people to move on. So there is still that 2 year window of supporting 2 languages. So, we might have two official languages someday, but no more than that. I have yet to see a auto-translate tool that works 100%. I do not believe that they exist. I guess there is f2c, but I am sure there are corner cases that fails on. To all using the current CMake language, have no fear, it will be supported in the future. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Wed, Feb 27, 2008 at 5:37 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: I think if the automated translation tool had proven itself for a couple of years, it would be perfectly reasonable to force people to move on. So there is still that 2 year window of supporting 2 languages. I have yet to see a auto-translate tool that works 100%. I do not believe that they exist. I guess there is f2c, but I am sure there are corner cases that fails on. That's 2 cantankerous languages and a rather general problem domain. CMake script is a rather limited language. Not that hard to map it to Lua. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Brandon Van Every wrote: That's 2 cantankerous languages and a rather general problem domain. CMake script is a rather limited language. Not that hard to map it to Lua. I don't know, I have heard about people using CMake for a general purpose language :) I don't think I have any idea what every single project using CMake is doing with the language. It would be much safer and easier to continue to support it in the core of CMake. I just don't believe that translation can work, and the fun part is that it can't even be proved that the translator works 100% of the time... Anyway, I think we have beat this horse enough for this thread. Arguing about a future hypothetical perfect translator is a waste of time... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Wed, Feb 27, 2008 at 8:58 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: That's 2 cantankerous languages and a rather general problem domain. CMake script is a rather limited language. Not that hard to map it to Lua. I don't know, I have heard about people using CMake for a general purpose language :) I don't think I have any idea what every single project using CMake is doing with the language. Only thing problematic I could see, is if someone's getting clever and using CMake script to generate CMake script. I think it would be reasonable to make such people untangle their metaprogramming. It would be much safer and easier to continue to support it in the core of CMake. It's 2x work to support CMake script and Lua indefinitely. I just don't believe that translation can work, and the fun part is that it can't even be proved that the translator works 100% of the time... That's not a realistic concern though. You will either decide to move on to Lua or you won't. Any amount of excuses can be invented if you aren't willing. That's how I lost the Chicken Scheme project BTW. Lotsa excuses about how the CMake build wasn't ready or was buggy for some reason, even though it proved itself in the field for 6 months without any real problems. Certainly no more problems than anyone has with a near-perfect build maintained in any language over the same time period. The Chicken Scheme author simply didn't want to get his hands dirty with CMake. He also tended to call every other piece of open source software buggy, except for Chicken Scheme of course. If I learned nothing else from that project, I learned about political will. There are technology problems and there are political problems. I can't solve those here. I can only agitate in a certain direction, point out what is possible, and knock down perceived barriers. I hope that in coming years you will consider the various technical merits and demerits of Lua. Perhaps someday, it will become your idea. Then you'll be more interested in automatic translation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
While the cmake language may not be beautiful, it works, and the users (developers) are not supposed to write programs with it. I do get your point that people should not *have* to program to do common tasks. Some other build systems seem to rely on the user to do far too much. The build system should include support for all common tasks at a high level as macros or commands etc. But I think you still need programming power for the corner cases large projects bump into. I second this. Large projects need some glue to correctly drive them. For instance we have +150 MSVC/XCode projects to manage and our managing framework is heavily scripted in CMake scripts with +10k LOC. Without the programming power of CMake we could not build a consistent framework and have such a flexibilty and easiness in CMakeLists.txt files, so in our case this feature is by far the most important one. Since we were able to achieve everything we need without using any other scripting language, I think that adding new scripting languages to CMake is not worth it. It prevents people from correctly learning the CMake scripting language which is powerful enough to build a strong, stable and consistent framework. --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake and Lua
In principle CMake implements two thing, - a scripting language, - and a make/build-file generator. As I understand it, these two things are currently mixed up in CMakeLib: all commands parse the arguments (scripting functionality) and then call the generator function with the found arguments, for instance this-Makefile-AddSubDirectory(.. This makes it hard to introduce a new scripting language, if it should not only be a wrapper of the current cmake commands. Isn't this your ansatz in your Lua experiment? http://www.cmake.org/Wiki/CMake:Experiments_With_Lua http://www.assembla.com/wiki/show/CMakeLua I would choose a different way: First I would split the current CMakeLib into two libs, one which implements the macro language, and the other which implements the generator stuff only, nothing knowing about any scripting/macro language. In VTK and ITK we did design a language independent toolkit and wrapped it into Tcl, Python, Java etc so we have done that and have a good feel for it. But for CMake I do not think it is a good idea for a couple reasons. One is fragmentation of the community/support. The other is that a non-trivial portion of CMake is written in the scripting language ala the Modules directory. So supporting multiple languages becomes problematic. Most languages are not designed to mix with other languages. I doubt you can mix python and Lua and expect them to be able to access each other's variables out of the box. But with the Modules directory we either have to have a copy of each module for every possible scripting language, on the fly converters between any two scripting languages, or something like that to make it work. Trying to figure out how to manage the mixed CMakeScript/Lua variables by itself is already a bit of an issue to providing a Lua binding much less adding other languages on top of that. Hopefully that makes some sense :) Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
The other is that a non-trivial portion of CMake is written in the scripting language ala the Modules directory. So supporting multiple languages becomes problematic. Most languages are not designed to mix with other languages. I doubt you can mix python and Lua and expect them to be able to access each other's variables out of the box. But with the Modules directory we either have to have a copy of each module for every possible scripting language, on the fly converters between any two scripting languages, or something like that to make it work. Trying to figure out how to manage the mixed CMakeScript/Lua variables by itself is already a bit of an issue to providing a Lua binding much less adding other languages on top of that. Hopefully that makes some sense :) While I agree that the variable problem between CMake-script and any other language is non-trivial, I think it becomes less of an issue once you do make it to a well known dynamic language like Lua. There already seem to be a handful of projects that bridge Lua to other scripting languages and deal with many things including variable bridging. Lunatic Python - two-way bridge between Python and Lua (best documentation) http://labix.org/lunatic-python Lux (embed Lua in Tcl, Python, Perl, Ruby) http://www.equi4.com/wikis/lua/25 Rua (use Lua under Ruby) http://rua.rubyforge.org/ Ruby-Lua http://raa.ruby-lang.org/project/ruby-lua/ Inline::Lua - Perl extension for embedding Lua scripts into Perl code http://search.cpan.org/~vparseval/Inline-Lua/lib/Inline/Lua.pm Calling Perl from Lua http://thomaslauer.com/comp/Calling_Perl_from_Lua Maybe some day there will be Parrot http://www.parrotcode.org/ http://www.parrotcode.org/talks/LuaOnParrot.pdf -Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Saturday 23 February 2008, Peter Kümmel wrote: Hi Ken, this is a reply to your email on the Lua list: http://marc.info/?l=lua-lm=120275861422593w=2 It is nice to see that there is interest in Lua as alternative scripting language. Since I've discovered Lua I thought it would be a nice drop-in for the actual CMake macro language. After having seen some presentations at FOSDEM, I'm even more convinced that having only limited programming functionality available in build files is a good thing. While the cmake language may not be beautiful, it works, and the users (developers) are not supposed to write programs with it. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Alexander Neundorf wrote: On Saturday 23 February 2008, Peter Kümmel wrote: Hi Ken, this is a reply to your email on the Lua list: http://marc.info/?l=lua-lm=120275861422593w=2 It is nice to see that there is interest in Lua as alternative scripting language. Since I've discovered Lua I thought it would be a nice drop-in for the actual CMake macro language. After having seen some presentations at FOSDEM, I'm even more convinced that having only limited programming functionality available in build files is a good thing. Because you've seen too much CMake-acrobatic? While the cmake language may not be beautiful, it works, and the users (developers) are not supposed to write programs with it. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Peter Kümmel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 2:06 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: After having seen some presentations at FOSDEM, I'm even more convinced that having only limited programming functionality available in build files is a good thing. What in particular confirmed this opinion of yours? I did not attend, but I read the schedule and noticed there were presentations for both CMake and SCons. Was it something the lecturers said? Audience questions? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Ken Martin wrote: In VTK and ITK we did design a language independent toolkit and wrapped it into Tcl, Python, Java etc so we have done that and have a good feel for it. But for CMake I do not think it is a good idea for a couple reasons. One is fragmentation of the community/support. Every time this fear of fragmentation/forks. Should we really care about it? I don't know. The other is that a non-trivial portion of CMake is written in the scripting language ala the Modules directory. So supporting multiple languages becomes problematic. Most languages are not designed to mix with other languages. I doubt you can mix python and Lua and expect them to be able to access each other's variables out of the box. But with the Modules directory we either have to have a copy of each module for every possible scripting language, on the fly converters between any two scripting languages, or something like that to make it work. Trying to figure out how to manage the mixed CMakeScript/Lua variables by itself is already a bit of an issue to providing a Lua binding much less adding other languages on top of that. Hopefully that makes some sense :) Yes, the existing modules are a problem. It makes no sense to support multiple languages there. Then it is only possible to provide a C++ interface so that all the module stuff works behind the scene (behind the interface), using one scripting language only. And if a new module should go upstream it must use this language. But all official-shipped modules could be made accessible through the C++ interface, so that one still could call the generator functions from a other language. Anyway, I'm not sure any more if my initial idea was really that good. Peter ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Monday 25 February 2008, Brandon Van Every wrote: On Mon, Feb 25, 2008 at 2:06 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: After having seen some presentations at FOSDEM, I'm even more convinced that having only limited programming functionality available in build files is a good thing. What in particular confirmed this opinion of yours? I did not attend, but I read the schedule and noticed there were presentations for both CMake and SCons. Was it something the lecturers said? Audience questions? Scons seemed more like a framework which you could use to write an actual build system. You actually have to write a program to build your software, and deal with a lot of low-level stuff. I also saw the scons files we had in KDE, and they were partly real programs. The build system should provide what you need without requiring that you actually need to program something. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 2:22 PM, Peter Kümmel [EMAIL PROTECTED] wrote: Then it is only possible to provide a C++ interface so that all the module stuff works behind the scene (behind the interface), using one scripting language only. And if a new module should go upstream it must use this language. But all official-shipped modules could be made accessible through the C++ interface, so that one still could call the generator functions from a other language. So, anyone who doesn't like the official CMake language, would have no incentive to contribute features to standard CMake. This is a form of community fragmentation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Brandon Van Every wrote: On Mon, Feb 25, 2008 at 2:22 PM, Peter Kümmel [EMAIL PROTECTED] wrote: Then it is only possible to provide a C++ interface so that all the module stuff works behind the scene (behind the interface), using one scripting language only. And if a new module should go upstream it must use this language. But all official-shipped modules could be made accessible through the C++ interface, so that one still could call the generator functions from a other language. So, anyone who doesn't like the official CMake language, would have no incentive to contribute features to standard CMake. This is a form of community fragmentation. Yes, this is a risk. But maybe it is worth the risk. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Peter Kümmel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Quoting Peter Kümmel [EMAIL PROTECTED]: Ken Martin wrote: In VTK and ITK we did design a language independent toolkit and wrapped it into Tcl, Python, Java etc so we have done that and have a good feel for it. But for CMake I do not think it is a good idea for a couple reasons. One is fragmentation of the community/support. Every time this fear of fragmentation/forks. Should we really care about it? I don't know. You are plain wrong assuming more languages to choice are good when in fact that choice is bad and harmful. If CMake allowed 10 scripting languages, it would effectively mean any CMake user needs to learn those 10 languages to be able to use CMake. Any one of those 10 languages a CMake user does not know, it means some module, or CMakeLists.txt, he cannot understand/improve/fix. One Language to rule them all, One Language to find them, One Language to bring them all and in the compiler bind them. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Pau Garcia i Quiles wrote: One Language to rule them all, One Language to find them, One Language to bring them all and in the compiler bind them. Nice, but wasn't the One destroyed? ;) Peter ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 3:14 PM, Peter Kümmel [EMAIL PROTECTED] wrote: Pau Garcia i Quiles wrote: One Language to rule them all, One Language to find them, One Language to bring them all and in the compiler bind them. Nice, but wasn't the One destroyed? ;) Actually, all of the rings lost their power at that time. Analogously, we'd forget about build systems and go into the West. We could speculate about who's the Dark Lord. By my demeanor I am surely an Uruk-hai captain. -) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake and Lua
I'm even more convinced that having only limited programming functionality available in build files is a good thing. While the cmake language may not be beautiful, it works, and the users (developers) are not supposed to write programs with it. OMG flame war Bring it! :) Seriously though, it probably depends on what you mean by write programs and limited programming functionality I think in the end you need a language you *could* at least write bad programs in :). Case in point the CMake language originally did not include many of the programming constructs it now has; macros, foreach, while, functions, etc. Heck a very basic version of the if statement was not added until a full six months after development was rolling along. It was intended to be pretty much declarative. But these features were all added because big projects need more than a declarative format. They need conditionals. And the really big projects need other constructs for code management. For example: VTK has around 20,000 lines of CMake code to build it (which is a bit absurd but...). When you get to 20,000 lines you need some form of structure to it, code reuse, etc, otherwise it just becomes a mess. Which is why CMake has include, macro, foreach etc. which are all staples of a programming language. I do get your point that people should not *have* to program to do common tasks. Some other build systems seem to rely on the user to do far too much. The build system should include support for all common tasks at a high level as macros or commands etc. But I think you still need programming power for the corner cases large projects bump into. Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Brandon Van Every wrote: Actually, all of the rings lost their power at that time. Analogously, we'd forget about build systems and go into the West. We could speculate about who's the Dark Lord. By my demeanor I am surely an Uruk-hai captain. -) Good closing words for this thread. See you in the West, Peter ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
I have testing CMake as my build system for medium sized proyects and i view that change to a tiny scripting instead of CMake macros can be good. For example in my project. i need stuff for compile other things that are not out of the box supported by CMake, for example antltr files for generate gramar lexers, templates files from various tools , IDL for diferent vendors, ui files for diferent vendors. Write this as MACROS is tedious and you end writting more lines that needed with a scripting language. Current cmakes macros are good for doing simple things, because you can do this things easy as a few lines of code more times. Also i think that core a scripting must be separate layers i don`t view and extra cost for this and it simplifies the process of add a new scripting language or migrate to a new one. Also a c++ plugin interface can be desirable for realy complex things, for example i view that CMake suport http out of the box, but other proyects must need integrate with other protocols, Ok this are really coner case that can be simplified easy with a python script, but seems mision imposible to do such a thing in CMake. if ITS modularize more the core of CMake and make the arquitecture more plugable the proyect can grow faster with the help of the comunity that can write modules for do other things not suported out of the box. This is the scenario i view for a winner build system in the open source community. -- Bests for CMake, José GutÃerrez http://www.oo4u.org ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Monday 25 February 2008, Ken Martin wrote: ... OMG flame war Bring it! :) How about: everybody should use Ruby, because all other languages suck ! ;-) Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 5:14 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: On Monday 25 February 2008, Ken Martin wrote: ... OMG flame war Bring it! :) How about: everybody should use Ruby, because all other languages suck ! ;-) Ruby's license sucks. The price of Ruby's nice language features is that it's slow. Anyways, if someone could explain to me why Rake matters, I'd listen. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Ken Martin wrote: Which is why CMake has include, macro, foreach etc. which are all staples of a programming language. Right, much better to spend time on something else, and use Lua for all these things. Add wxLua , and the graphical interface becomes easy too. CMakeSetup is nice, but i can't organize options the way i want. So would it be possible to make some hybrid kind of Cmake, which makes it possible to slowly migrate. Or how do you think about using existing modules in Cmake syntax. Maybe calling Cmake macros from a Lua script? How exactly did you wrap in Lua what is there now? Can you mix, or is it just a change or two, and Cmake becomes a lua script? I think to give this a chance, there need to be both at the same time, and slowly migrate modules and projects. Just curious, and like Lua much that i use it as scripting language in my own project, using Cmake to generate the binding and to build it :-) Klaas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 5:15 PM, klaas.holwerda [EMAIL PROTECTED] wrote: Ken Martin wrote: Which is why CMake has include, macro, foreach etc. which are all staples of a programming language. Right, much better to spend time on something else, and use Lua for all these things. Historically, that would have been true, at CMake's beginning. I don't see why it is true now. The Kitware team is experienced with the CMake codebase and hasn't shown much evidence of employee turnover. I don't get the impression that they've spent tons of energy adding the recent scoping and function support. Seems like their approach is cost-effective as compared to ripping everything up to stick Lua in there. Add wxLua , and the graphical interface becomes easy too. I thought CMake had a wx frontend at some point. If it didn't go anywhere, it's from somebody's lack of follow-through, not a language barrier. Lotsa people do wx from C++. CMakeSetup is nice, but i can't organize options the way i want. Customizing the GUI for your purposes doesn't benefit the off-the-shelf CMake community. If we try to teach everyone how to use the standard GUI and you've done something completely different, then depending on how different you made it, it might not be worth calling it CMakeSetup. On the other hand, if you are wishing for modest customizations, put your specific ideas on the mailing list, see if others agree, make a feature request, etc. Such features do tend to get done, if there's a clear case for how they benefit people and they're doable. So would it be possible to make some hybrid kind of Cmake, which makes it possible to slowly migrate. Sure. You personally could make it right now. Getting Kitware to agree to some kind of future path and halfway house is a whole 'nother matter. I don't think such a migration can be slow. The slower it is, the longer everyone is overburdened with supporting 2 scripting languages. I think a migration needs a language translator, so that builds can be migrated quickly to the new, preferred, standard language. CMake script -- Lua translation is certainly doable, but someone would have to do it, and it would be real work. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Ken Martin wrote: other's variables out of the box. But with the Modules directory we either have to have a copy of each module for every possible scripting language, on the fly converters between any two scripting languages, or something like that to make it work. Trying to figure out how to manage the mixed Surely the idea is that modules should be self contained: they expose data by registering it into the CMake core (possibly with callbacks) and interface to other modules through the core. Modules can be in different languages without the issue you indicate (or, the modularity is poor and the binding too tight). James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Tue, Feb 26, 2008 at 2:12 AM, James Mansion [EMAIL PROTECTED] wrote: Ken Martin wrote: other's variables out of the box. But with the Modules directory we either have to have a copy of each module for every possible scripting language, on the fly converters between any two scripting languages, or something like that to make it work. Trying to figure out how to manage the mixed Surely the idea is that modules should be self contained: they expose data by registering it into the CMake core (possibly with callbacks) and interface to other modules through the core. Modules can be in different languages without the issue you indicate (or, the modularity is poor and the binding too tight). Seems like an invitation to polyglot development. I regularly have to read the contents of modules to find out what they do. I suppose for me personally, it wouldn't be a dealbreaker to have to read the raw code of FindXXX in 7 different languages. However, it would make it a PITA to install and build CMake, with all the different languages that would have to be present to facilitate it. Not all systems are Linux, it isn't a given that all the languages are packaged and nicely pre-deployed. I also suspect that the majority of developers would be less forgiving about the scattered, haphazard quality of the documentation that would inevitably result. Mr. Miyagi from The Karate Kid said something like, better to know 1 kick well. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
I am not seeing the merit of trying to support multiple scripting languages. This fragments CMake into many sub-language communities. Who would handle all the inevitable bugs? It's many times the work of maintaining a quality implementation with 1 scripting language. I don't think this is necessarily as bad as you think. For a real world example, look at Cocoa and Objective-C in the Mac world. Apple's OS X is a direct descendant of NeXTSTEP which used Cocoa/Objective-C to implement its GUI frameworks. Mac classic however did not. To hold over old Mac classic people until they could rewrite, Apple introduced a second completely independent framework called Carbon, but they told people they should use Cocoa to get first-class looking applications. As you describe, in this case, maintaining two separate frameworks was a pain in the butt and each had different bugs and differences in behavior. So I agree, this is a bad situation. Cocoa is by far the superior framework, but many developers unfamiliar with NeXTSTEP or new to OS X refused to touch Cocoa because they didn't want to learn Objective-C. Objective-C is a very minimal superset of C; basically C with objects and a very dynamic runtime. It only takes a day to learn if you already know C or C++. Yet, there has been huge resistance to learning Objective-C. But Objective-C, being a really dynamic language has lots of cool features and tricks. It supports reflection, introspection, and has a robust runtime, so language bindings turned out to be very possible and not terribly difficult to implement. So over the years, different language bridges have been developed. The two biggest and most complete are PyObjC and RubyCocoa. PyObjC has been around for 10-20 years and was used heavily in the NeXTSTEP days on Wall Street. Anyway, Apple has finally decided to include PyObjC and RubyCocoa officially in the latest version of OS X. This is great because now people who don't want to be bothered to learn Objective-C may now use other languages to access Cocoa. And Carbon is now declared deprecated so this framework can go away. So a few of things to note: - The language bridge is made possible to due good reflection, introspection, and dynamism. Only languages that have similar capabilities can bridge to Obj-C well. This means some languages like C++ will never bind to Objective-C well. (Objective-C++ has a different approach and purpose.) - To make the bridge easy to implement and maintain, the bridge languages don't change a lot of things around. Method names maintain a 1-to-1 correspondence and design patterns don't change. (An earlier hand-made Java-ObjC bridge by Apple violated this and was a dismal failure.) - Because of the 1-to-1 correspondence, Cocoa framework questions can generally be answered by anybody, regardless of language. - There are some nasty areas in writing an Obj-C bridge, mainly dealing with the pure-C aspects of the language since there is no introspection/reflection/runtime support to figure these things out. - The language bridges don't necessarily have to be known about and supported by Apple. 3rd party communities implemented all the language bindings. Apple realizing this, introduced BridgeSupport in the lastest OS X, which provides more meta information about the frameworks so language bindings are even easier to write, especially for the nasty areas. With respect to CMake, I believe if done 'right', (I know, big 'if'), then building a language bridge shouldn't be hard, shouldn't fracture the community, and won't require Kitware to know about/support or even care what languages out there are being used to write scripts. It's not obvious to me how to implement this the 'right' way though. With the native CMake-script language, there are certainly impedance mismatches with 'real' languages. However, if a Lua implementation can be completed, I think all this will fall into place. Also, since Lua has really great introspection/runtime capabilities, it might be possible to bridge across Lua. There are already projects out there that let you bridge/embed Lua with Ruby, Perl, and Python. And maybe someday Parrot will be finished. -Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Sun, Feb 24, 2008 at 8:03 AM, E. Wing [EMAIL PROTECTED] wrote: Apple introduced a second completely independent framework called Carbon, but they told people they should use Cocoa to get first-class looking applications. Kitware + the CMake community do not have the resources of Apple. Cocoa is by far the superior framework, but many developers unfamiliar with NeXTSTEP or new to OS X refused to touch Cocoa because they didn't want to learn Objective-C. Lua is significantly more popular than Objective-C even today. http://www.tiobe.com/index.html?tiobe_index Find me evidence of people who refuse to touch Lua. Trying to please everyone by technical means will result in marginal gains in popularity. A marketing campaign would get a lot more bang for the buck. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote: On Sun, Feb 24, 2008 at 8:03 AM, E. Wing [EMAIL PROTECTED] wrote: Apple introduced a second completely independent framework called Carbon, but they told people they should use Cocoa to get first-class looking applications. Kitware + the CMake community do not have the resources of Apple. I think you totally missed the point of my entire message. Carbon was an example of a waste of resources. Apple barely had the resources to support Carbon and why it is now deprecated. The point of the message was that by embracing the flexibility of the Obj-C runtime, the community was able to write language bindings themselves separating the framework from the language. I believe Peter's original suggestion was to cleanly separate the CMake project generation capabilities from the scripting language. I was citing a real world case (Cocoa) where this worked and how it was accomplished (Obj-C bridging). Cocoa is by far the superior framework, but many developers unfamiliar with NeXTSTEP or new to OS X refused to touch Cocoa because they didn't want to learn Objective-C. Lua is significantly more popular than Objective-C even today. http://www.tiobe.com/index.html?tiobe_index Find me evidence of people who refuse to touch Lua. Again, you missed the point entirely. This isn't about Obj-C vs Lua or any other languge. The point was that by providing a language bridge, the whole language wars argument gets thrown out the window. The user now gets to decide what language they want to use to access the Cocoa framework. I believe Peter's suggestion is the same. People who want to use CMake (the project generator) should be able to decide for themselves what language they want to write in. The only analogy worth drawing about refusing to touch Obj-C is the same refusal to touch CMake's native scripting language. I would extend that by stating that if people who could benefit directly from Cocoa are refusing to touch an easy language like Obj-C (and ignore the bridges) which has some really awesome features and elegance that C# users are only starting to figure out, then even fewer people are going to be willing to use CMake-script. -Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Sun, Feb 24, 2008 at 12:36 PM, E. Wing [EMAIL PROTECTED] wrote: Again, you missed the point entirely. This isn't about Obj-C vs Lua or any other languge. The point was that by providing a language bridge, the whole language wars argument gets thrown out the window. So are you going to write this framework for us, that makes all the work of supporting multiple languages magically go away? People who want to use CMake (the project generator) should be able to decide for themselves what language they want to write in. No they shouldn't. They can pay for that kind of support. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Sun, Feb 24, 2008 at 12:56 PM, E. Wing [EMAIL PROTECTED] wrote: On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote: So are you going to write this framework for us, that makes all the work of supporting multiple languages magically go away? If you bothered actually reading my comments, you might have noticed the paragraph where I said it's not immediately obvious how to refactor these things. But by finishing the Lua integration, I believe there is a chance this will become more clear, and one of two things will happen. 1) It becomes obvious how to refactor things so people can write their own language bridges. 2) It becomes obvious refactoring is not so easy, and the way to bridge is directly through the Lua runtime, similar to how Obj-C/Cocoa is bridged. It's lotsa extra work to support lotsa extra languages. We've all got things to do, we're not made of time and money. Selling people on a Lua migration is difficult enough as it is. Why don't you concentrate on *that* agenda, before bothering with even loftier stuff? People who want to use CMake (the project generator) should be able to decide for themselves what language they want to write in. No they shouldn't. They can pay for that kind of support. That's a nonsensical statement to me. The point is, they can either implement the multi-language support themselves, or pay people to implement it for them. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote: On Sun, Feb 24, 2008 at 12:56 PM, E. Wing [EMAIL PROTECTED] wrote: On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote: So are you going to write this framework for us, that makes all the work of supporting multiple languages magically go away? If you bothered actually reading my comments, you might have noticed the paragraph where I said it's not immediately obvious how to refactor these things. But by finishing the Lua integration, I believe there is a chance this will become more clear, and one of two things will happen. 1) It becomes obvious how to refactor things so people can write their own language bridges. 2) It becomes obvious refactoring is not so easy, and the way to bridge is directly through the Lua runtime, similar to how Obj-C/Cocoa is bridged. It's lotsa extra work to support lotsa extra languages. We've all got things to do, we're not made of time and money. Selling people on a Lua migration is difficult enough as it is. Why don't you concentrate on *that* agenda, before bothering with even loftier stuff? I am in agreement with you here. Again, part of my discussion of the Obj-C bridging was the fact that the community wrote it all, not Apple. Apple did not need to know or care what bridges were existence. However, they saw the benefit in the bridges and decided to make bridging even easier for people to write by introducing BridgeSupport. To draw the analogy, I would say CMake could benefit if language bridging was something that was manageable. But Kitware won't have to write or support all the bridges that might come. But I agree that starting with just Lua to begin with is a good strategy. But as a side effect of completing a fully functional Lua binding, I believe it will become more obvious on how to support bridging in general. Then if anybody in the community is interested in different languages, they have a starting point and proof it can be done. People who want to use CMake (the project generator) should be able to decide for themselves what language they want to write in. No they shouldn't. They can pay for that kind of support. That's a nonsensical statement to me. The point is, they can either implement the multi-language support themselves, or pay people to implement it for them. Yes, I don't expect Kitware to implement and support any additional languages beyond Lua. (And even Lua is in question right now.) I fully expect additional language support will be a grass-roots effort outside of Kitware. However, with a working Lua binding, that may become the basis for future bridges as there will either be source code showing how it's done, or somebody will bridge Lua. -Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake and Lua
Hi Ken, this is a reply to your email on the Lua list: http://marc.info/?l=lua-lm=120275861422593w=2 It is nice to see that there is interest in Lua as alternative scripting language. Since I've discovered Lua I thought it would be a nice drop-in for the actual CMake macro language. Here I wanna post some ideas about the general architecture. In principle CMake implements two thing, - a scripting language, - and a make/build-file generator. As I understand it, these two things are currently mixed up in CMakeLib: all commands parse the arguments (scripting functionality) and then call the generator function with the found arguments, for instance this-Makefile-AddSubDirectory(.. This makes it hard to introduce a new scripting language, if it should not only be a wrapper of the current cmake commands. Isn't this your ansatz in your Lua experiment? http://www.cmake.org/Wiki/CMake:Experiments_With_Lua http://www.assembla.com/wiki/show/CMakeLua I would choose a different way: First I would split the current CMakeLib into two libs, one which implements the macro language, and the other which implements the generator stuff only, nothing knowing about any scripting/macro language. Then a binding of the macro language to the generator lib gives you a backward compatible CMake version. If only this is done, nothing is won. But with this layout, it would be much easer to use other scripting languages. With this architecture you don't have to definitely exclude all other scripting languages when choosing Lua as additional new language. Kitware could officially support Lua and KitwareScripting, the old macro language, and at the same time provide a well proven cross-plattform build-file generator library which could easily be used by other scripting languages (imported as an external module). On the long run this gives you a much greater user/developer base, and gives the build-file generator library the chance to become the standard in cross-platform builds systems. Some scenarios I could imagine: - if there is a binding done with http://www.swig.org/ CMake could be used by all popular scripting languages - maybe Trolltech finds it convenient to replace their proprietary build-file generators, and join forces with Kitware. Then it is possible that CMake is sometimes part of Nokia/Symbian projects' build process - someone binds CMake to autotools/m4 (don't know if this is possible) - a PHP binding to manage the build process with a browser, don't know why someone would do this ;) - with a bjam binding it finds its way into boost (What's the current status of boost's cmake branch?) - CMake everywhere in analogy to the slogan of TT - SCons uses CMake to generate build-files as alternative to their build files - with Kross the scripting language becomes transparent http://kross.dipe.org/ More scenarios or comments are welcome. Best regards, Peter Kümmel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Hopefully other people will spend time debating the merits / demerits of this, as people have gotten sick of hearing me talk about CMake and Lua as of late. I'm happy that my irritance has caused people to continue to discuss the possibilities, however. I will make one point: On Sat, Feb 23, 2008 at 6:20 AM, Peter Kümmel [EMAIL PROTECTED] wrote: If only this is done, nothing is won. But with this layout, it would be much easer to use other scripting languages. With this architecture you don't have to definitely exclude all other scripting languages when choosing Lua as additional new language. I am not seeing the merit of trying to support multiple scripting languages. This fragments CMake into many sub-language communities. Who would handle all the inevitable bugs? It's many times the work of maintaining a quality implementation with 1 scripting language. It wouldn't get handled, so CMake's reputation would suffer because the Python implementation isn't so good or whatever. How do I advise someone who's using a different language? I can't just show them working code, I can't just tell them to file a bug report with a trivial reproducer. I have to understand their language, or tell them how to abstractly solve the problem, or just punt. Not all scripting languages have nice licenses. For instance, Ruby has a somewhat onerous Artistic License, compared to CMake's BSD license. Most of the languages other than Lua are somewhat bloated, both in terms of execution size and speed. In short, I do not see value in trying to be all things to all people. That's an expensive way to do business. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
- The source code seems to have been crappified by windows. There's missing +x permissions on executable files and cr-lf linefeeds everywhere. - The source does: #include lua.h but the bootstrap/cmakelists.xt does not search for paths to it. Under my Ubuntu box, lua.h is located in lua5.1/lua.h or lua5.0/lua.h, not under the main /usr/include. So I'm wondering if there is a cleaned up version of the code yet. I'm having a hard time dealing with both the cr-lf and the Lua detection on my Mac. - The approach of a single cmCommand.cxx to parse functions is probably limiting as it makes it harder to make the command syntax more flexible. I wanted to comment on this. I think this is a workable situation. I was thinking, instead of trying to change things at the C++ level, it would be a lot easier to handle this at the Lua level. We can create a CMake/LuaUtility module which always gets included and create a public API there. Each public API function in here basically just calls the CMake/Lua function that was binded in cmCommand.cxx. But in the utility module, we do all the argument parsing and validation we see fit. I've submitted an example and updated the page: http://www.cmake.org/Wiki/CMake:Experiments_With_Lua The example shows different ways scripters may want to pass files to add_library and a simple function that handles it. Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Jesper Eskilson wrote: Many systems (even the *really* large ones) are actually very simple to their layout; projects are often isomorphic so that each CMakeLists.txt is more or less just a list of files to compile. But other systems (both large and small) are simply to complicated to maintain a build system for without a proper language at your disposal. GCC and the Linux kernel are good examples of the latter (neither of which actually do have a good build system language, but that's another story). A little off topic, but GCC via gcc_xml http://www.gccxml.org/HTML/Index.html is built by CMake, and did not require a language. Most of the complication comes at build time with custom commands that generate files that generate files, that generate files. The build script it self does not have to do much programming. Most of the hard work is pushed to build time, and not CMake time. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 29, 2007 2:18 AM, Jesper Eskilson [EMAIL PROTECTED] wrote: Brandon Van Every wrote: On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. No offense, but you're not really in a position to determine what constructs are benefitial for people in their own build systems. I'm saying any reasonable implementation of scope would satisfy me at present. We all have our points of view about how important various things are. Alexander has gone on record as anti-complexity; he Considers Programming Harmful in a build system. I don't agree with him; I figure if I need scope today, perhaps I'll need OO or FP 5 years from now. People in the computer industry have a history saying newfangled stuff isn't needed, and people are always proven to be partly wrong. I don't have reactionary views about using fullblown programming languages in build systems. I don't feel threatened by them. I do think that people can run away with their abstractions and turn their build system into a PITA. But I also think that large scale open source projects that *I* have to deal with, have some cultural safeguards against that. I'm not worried about being tortured by someone else's horrible build system... and if it's really that bad, I have a consulting opportunity to write something better. I'm very conscious of the marketing value of fullblown programming languages. People think they need them, whether they need them or not. I may only want some very basic scope out of Lua, but I'd be quite happy if the world flocked to CMake for other Lua bells and whistles. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 29, 2007 12:37 PM, Brandon Van Every [EMAIL PROTECTED] wrote: We all have our points of view about how important various things are. Alexander has gone on record as anti-complexity; he Considers Programming Harmful in a build system. I don't agree with him; I figure if I need scope today, perhaps I'll need OO or FP 5 years from now. It occurs to me, furthermore, that CMake is a self-selecting community for discussing the issue. CMake doesn't have fancy programming capabilities. So, if that's a dealbreaker for someone, they probably won't stick around. The people who do stick around, are likely to tell newcomers that a lack of programming capabilities is just fine. This culture is enforced by the technology. CMake is a fairly successful build system, and so is Autoconf, so maybe there's something to be said for this culture. But it is a culture, and it's probably better to solicit perspectives outside the culture. Consequently, I'm starting to ask around on more general purpose build engineering lists, about what value they see in OO or other programming constructs. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: As DSL based on Lua != Lua, assuming Kitware gets rid of documentation and bugs in the language might be too optimistic. Look for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based DSL for hardware description, like Verilog or VHDL, but it's so different from Ruby you need to produce the whole documentation again. So? So far I'm the only person who has proposed changing Lua syntax. I've only listed 2 items: excessive quotes and unpack(table). Nothing would stop anyone from using quotes all over the place or unpack(table), i.e. standard Lua would still work. It may even be possible for these minor tweaks to be transparently corrected as far as 3rd party Lua libraries are concerned. If it's 95% Lua it's still Lua. We're talking about a 1 page addendum to the docs, tops. Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get for free, whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. We already had the extended discussion about possible CMake scope implementations, so I'm not understanding what you're asking. I assumed that Kitware is ready to act when they have time to do so. Did you miss that discussion? Did it leave you with a bunch of unresolved questions? If so, I'd suggest going back into the archive and responding to specific things you're unclear about. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
(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
Re: [CMake] CMake with Lua Experiment
Is backward compatibility with the current language a goal of the LUA experiment? I ask because the examples spoken of on this list appear to be trying to mimic the current CMake syntax. Right now I think it's just an experiment to see how things might work, how much effort would be involved, and how much of an impedance mismatch there will be with how things are currently done. It sounds like things may not progress any further unless a real long term vision for CMake is developed and embraced. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
I'd also like a shorter way to dereference a table than unpack(table). Seriously, this is a total non-issue and unpack is totally unnecessary. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Quoting Brandon Van Every [EMAIL PROTECTED]: Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get for free, whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. We already had the extended discussion about possible CMake scope implementations, so I'm not understanding what you're asking. I assumed that Kitware is ready to act when they have time to do so. Did you miss that discussion? Did it leave you with a bunch of unresolved questions? If so, I'd suggest going back into the archive and responding to specific things you're unclear about. Do you mean these threads? http://www.cmake.org/pipermail/cmake/2005-March/006235.html http://www.cmake.org/pipermail/cmake/2005-June/006725.html If that is so, yes, I guess I missed them (I was not using CMake back then :-). If you are talking about a different thread, could you please tell me which one? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:13 AM, E. Wing [EMAIL PROTECTED] wrote:
(Aside: what's with the cm_ prefix?)
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.
Yeah but that's your fault. :-) Do enough CMake and you're gonna
know that add_library isn't something anyone made up. I will admit
that a few of the uncommon functions could throw me. Like site_name,
which I only learned the other day after 2 years of hardcore staring
at CMake all the time. But I looked it up no big deal, right?
Furthermore, the CMake 2.6 docs have a better breakdown, there's a
CMake Commands Only section with a HTML index. These are separate
from the standard modules, which now have their own section. Module
names are exceedingly verbose, you're not going to mistake them. So
it's trivial to learn the reserved commands, there's maybe ~60 of
them, all concisely indexed in one place. The depreciated commands
have been moved out, thinning the ranks.
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:
In both cases, the function cm_add_library receive 5 strings as arguments.
No, we're talking past each other. I said I figured it out after
reading the docs for 15 minutes. I was saying, in a long-winded
manner, that CMake script's ${list} is equivalent to Lua's
unpack(table), and that CMake is less verbose than Lua for list/table
dereferencing. Since this is an operation that I do all the friggin'
time in 1/2 the lines of code I write, I consider it important.
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)
And I think rewriting all the CMake functions to dereference
lists/tables on the user's behalf is busywork. Nor do I, as a
programmer, want my lists/tables automagically dereferenced. When
it's my turn to write standard modules, macros, or functions, I want
clear expectations about who's gonna do the work. What the expected
type of input is, and what an error 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.
And a bit smaller.
As far as Ruby syntax is concerned, I don't see how it is
significantly different than Lua.
And a bit more PCRE. Lua's inherent regexes are weird.
All the Ruby code I've seen also has
quotes around string literals and commas separating items in lists.
Ok my bad. I keep thinking of Ruby as souped up Perl. Seems like
Perl, Make, CMake, and various shells are the sane ones as far as
string entry.
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.
Ain't gonna happen. The market has spoken: Lisp is weird. People
will use it, and its use may even increase, but it's never going to be
a majority language. Rather, the majority languages will steal Lisp
features and make them less weird.
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.
But that's wrong. Should be
add_library(myLibraryName, STATIC, ${listOfFilesFound})
where of course we've implemented ${} instead of unpack() ;-)
For any given CMake function, we know what argument types we expect.
The programmer is responsible for dereferencing, we're not going to do
it for them. We just have to parse the keywords like STATIC, and pay
attention to fixed positions at the beginning of an argument list. In
fact, come to think of it, if it's a CMake reserved function, hand it
off to a special argument processor, would solve much of the problem.
Then you're just down to changing Lua table constructors, so that
they don't require quotes.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:59 AM, Brandon Van Every [EMAIL PROTECTED] wrote: For any given CMake function, we know what argument types we expect. The programmer is responsible for dereferencing, we're not going to do it for them. We just have to parse the keywords like STATIC, and pay attention to fixed positions at the beginning of an argument list. In fact, come to think of it, if it's a CMake reserved function, hand it off to a special argument processor, would solve much of the problem. Then you're just down to changing Lua table constructors, so that they don't require quotes. Unfortunately it has to work for user created functions also, so I guess it's not quite so simple. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:17 AM, E. Wing [EMAIL PROTECTED] wrote: Right now I think it's just an experiment to see how things might work, how much effort would be involved, and how much of an impedance mismatch there will be with how things are currently done. It sounds like things may not progress any further unless a real long term vision for CMake is developed and embraced. Gee you want one of those? :-) Here's one: happy, shiny programmers using a happy, shiny, fullblown programming language to implement entire build systems with little or no reference to external Perl, Python, or Ruby code. People wouldn't have much need for those if CMake's language features were sufficient. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:40 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: Do you mean these threads? http://www.cmake.org/pipermail/cmake/2005-March/006235.html http://www.cmake.org/pipermail/cmake/2005-June/006725.html These are not the threads you're looking for. If you are talking about a different thread, could you please tell me which one? lexical scoping http://public.kitware.com/pipermail/cmake/2007-November/017385.html Must say, I couldn't find this by using the Kitware mailing list search engine on the keywords lexical scoping. Most baffling since it's the subject line. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:20 AM, E. Wing [EMAIL PROTECTED] wrote: I'd also like a shorter way to dereference a table than unpack(table). Seriously, this is a total non-issue and unpack is totally unnecessary. The argument evaluation model matters. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Variable scoping (was Re: [CMake] CMake with Lua Experiment)
Quoting Brandon Van Every [EMAIL PROTECTED]: On Nov 28, 2007 3:40 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: Do you mean these threads? http://www.cmake.org/pipermail/cmake/2005-March/006235.html http://www.cmake.org/pipermail/cmake/2005-June/006725.html These are not the threads you're looking for. If you are talking about a different thread, could you please tell me which one? lexical scoping http://public.kitware.com/pipermail/cmake/2007-November/017385.html Must say, I couldn't find this by using the Kitware mailing list search engine on the keywords lexical scoping. Most baffling since it's the subject line. Wow. I did not read a single message in that thread. I would have suggested inlining the scope of the variable in the variable name, like Ruby does, instead of SET, SET(LOCAL ...), VARIABLE_SCOPE, etc: * variable = local variable * @variable = instance variable * @@variable = class variable * $variable = global variable * VARIABLE = constant Of course it would be different in CMake. Here comes a quick'n'dirty proposal: * variable = global variable (keep compatibility with CMake 2.4) * @variable = local variable (for example, inside a macro, if, foreach, etc) * @@variable = module (= file) variable (for instance, for Find.cmake modules). It does not exist outside the current file (even INCLUDE'ing a file which defines @@variable would NOT make @@variable available outside the file which defined it). * VARIABLE = constants defined by modules (Find.cmake), cannot be changed after setting it (this way it's impossible to accidentally modify for example QT_LIBRARIES in a CMakeLists.txt) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Ya know, if we took all the energy and time that has gone into debating this issue and instead focused it on CMake dev we might solve some problems a bit quicker. Mike ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 9:39 AM, Mike Jackson [EMAIL PROTECTED] wrote: Ya know, if we took all the energy and time that has gone into debating this issue and instead focused it on CMake dev we might solve some problems a bit quicker. Not really. In terms of my personal energy, it was absolutely trivial to entertain this discussion so far. And as far as I'm concerned, such discussions are important before just leaping off in some direction that's expensive to pursue. But if you're ready to just do something, by all means do it. There's a CMake lexical scoping paradigm just waiting to be implemented that we already had a long discussion about. I'm not talking about that because as far as I'm concerned, we already said what needed to be said. I do think Pau's idea about using a few special characters to distinguish variable name scope has merit, but I will let others debate the pros and cons of it. Frankly, I see it as a race between the supposed ease of improving the CMake language, and the demonstrated ease of slapping Lua into it. With provisios about whether we really want straight Lua; at present I don't, so I'm inclined towards more work. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Wednesday 28 November 2007, Brandon Van Every wrote: On Nov 28, 2007 3:17 AM, E. Wing [EMAIL PROTECTED] wrote: Right now I think it's just an experiment to see how things might work, how much effort would be involved, and how much of an impedance mismatch there will be with how things are currently done. It sounds like things may not progress any further unless a real long term vision for CMake is developed and embraced. Gee you want one of those? :-) Here's one: happy, shiny programmers using a happy, shiny, fullblown programming language to implement entire build systems I for one really don't want that. I don't want a full blown programming language in my build scripts. I don't want to understand actual programs when looking at build files. IMO it is ok that the cmake language is limited, this way you don't end up with programs as build files. This is what can happen if you use scons, then you have programs as build scripts. And everybody can program something more fancy. IMO this is wrong for a build system. Still having some type of variable scoping would be nice to have :-) Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 1:28 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: On Wednesday 28 November 2007, Brandon Van Every wrote: On Nov 28, 2007 3:17 AM, E. Wing [EMAIL PROTECTED] wrote: Right now I think it's just an experiment to see how things might work, how much effort would be involved, and how much of an impedance mismatch there will be with how things are currently done. It sounds like things may not progress any further unless a real long term vision for CMake is developed and embraced. Gee you want one of those? :-) Here's one: happy, shiny programmers using a happy, shiny, fullblown programming language to implement entire build systems I for one really don't want that. I don't want a full blown programming language in my build scripts. I don't want to understand actual programs when looking at build files. IMO it is ok that the cmake language is limited, this way you don't end up with programs as build files. This is what can happen if you use scons, then you have programs as build scripts. And everybody can program something more fancy. IMO this is wrong for a build system. Still having some type of variable scoping would be nice to have :-) I somewhat agree with you. I'm not a fan of here's this tweaky thing you can do in Lua or Ruby. The few times I've tried to be helpful when a group was trying to get their build system off the ground (was it OpenSceneGraph or G3D, I forget?) I railed against programmatic approaches. It's way easier for me to understand straight CMake script than a pile of gratuitous abstractions that some programmer thought would be kewl. *However*, the need for robust scoping has been proven in my own and other people's work. As far as I'm concerned it's not just a nice to have item. Strategically, over the next 10 years, it is an essential item to have. Or CMake will someday be regarded as an unacceptable toy, incapable of meeting the complexity requirements of the software of the day. CMake is currently ahead of the competition in terms of capabilities; over the long haul, that happy fact is not guaranteed. Just as we all hate Autoconf now, if CMake is not forwards-looking as far as capabilities, someday we will all hate CMake. [*] Because I see the need for scoping at present, I'm willing to concede the possibility that Object Orientation, or some other higher level organizational paradigm, may be needed in the future. I don't know at what point in the future, and I expect later rather than sooner, but nevertheless technology marches on. ASM code gave way to C code, C code gave way to C++ code, C++ code gave way to Java code. Each generation of programmers claimed a lack of need, and each generation is consistently proven to be partly wrong. The old technologies and paradigms persist, but new technologies and paradigms emerge and capture large chunks of programmer marketshare. I'm sensitive to the imperatives of marketshare. I want more money in CMake consulting. I want more money in Open Source cross-pollenation between Unix and Windows. So, if fancier programming constructs make a tool vastly more popular, I take that into consideration. [*] Frankly some people hate CMake now, and they don't make it a secret. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Brandon Van Every wrote: On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: As DSL based on Lua != Lua, assuming Kitware gets rid of documentation and bugs in the language might be too optimistic. Look for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based DSL for hardware description, like Verilog or VHDL, but it's so different from Ruby you need to produce the whole documentation again. So? So far I'm the only person who has proposed changing Lua syntax. I've only listed 2 items: excessive quotes and unpack(table). Nothing would stop anyone from using quotes all over the place or unpack(table), i.e. standard Lua would still work. It may even be possible for these minor tweaks to be transparently corrected as far as 3rd party Lua libraries are concerned. If it's 95% Lua it's still Lua. We're talking about a 1 page addendum to the docs, tops. Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. No offense, but you're not really in a position to determine what constructs are benefitial for people in their own build systems. Build systems look very different in different places, and assuming that you know whats best for everybody is a good way to make people want to move away from CMake. Many systems (even the *really* large ones) are actually very simple to their layout; projects are often isomorphic so that each CMakeLists.txt is more or less just a list of files to compile. But other systems (both large and small) are simply to complicated to maintain a build system for without a proper language at your disposal. GCC and the Linux kernel are good examples of the latter (neither of which actually do have a good build system language, but that's another story). But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get for free, whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. No, but having (or being) a real programming language is still one of the main benefits of using SCons (IMO). Still, I went with CMake for our build system, primarily due to the superior support for generating Studio project files, and the fact that SCons has *major* performance issues, especially on Windows. I would like to claim that the input to the build systems (Makefiles, SConsctruct, CMakeLists.txt, etc.) should be considered as source code, with all the implications that has: checked into version control, subject to code quality standards, subject to code review, etc. Given that standpoint, having a real programming language in your build system is very natural. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Hi Ken, Wow, thank you for playing with this. I personally think it's great. Every so often, I have to write some evil stuff in CMake script, and it always leaves me frustrated with things sometimes not working correctly. Working with a well known and well defined language is a big plus for me, and also makes it easier to convince others people to pick up CMake. Remember the argument 'I don't want to learn another language' also works against CMake because the majority of people are not CMake users already. Having a simple language that is known, proven, and documented is a real way to get past the barrier to entry. Of all the scripting languages, I've found Lua to be both one of the easiest to pick up by non-scripters, and also one of the easiest for C/C++ programmers to quickly understand without triggering a visceral response in them. The syntax is elegant yet powerful, and Lua syntax more closely resembles C/C++ than many other popular scripting languages which makes it friendly to C/C++ people. Since the majority of people using CMake are C and C++ people, I think it is important to consider the latter too because I was once burned by having to pick up Tcl quickly in a predominantly C environment and I struggled with it. Habits and conventions I took for granted in C like whitespace and braces were something I automatically ignored, while it turned out to be incredibly significant in a small piece of Tcl code I was trying to get to work. (And the Tcl compile/runtime error I got was useless.) For me, Lua has been very compatible with the C mental model, with only a few annoyances (like != in C is ~= in Lua). And from a marketing standpoint, it's easy to say, 'using the language of World of Warcraft, Far Cry, Baldur's Gate, Grim Fandango, Escape From Monkey Island, and many others' and get people excited. So some more specific notes: The Windows line feeds and whatnot are mucking up my build attempt. I don't think you need to use unpack. You should be able to just pass a table. It is possible to write the implementation detail to handle either case I believe. It's true that CMake's language currently gives some nice features like the ability to omit commas and quotes, and case-insensitivity. There is a new macro processor for Lua that is supposed to help with these kinds of things with the intent of helping projects create their own domain specific customizations. It works on top of Lua so you don't have to modify Lua itself. I've never used it myself and don't know it's capabilities and limitations. The risk of this though is that you now deviate from standard Lua documentation. However, if it can be used in limited scenarios, there might be some benefits. If quotes and commas are a real pain and you don't want to use the macro thing, you can also pass things in as block strings and parse them yourself, but I always worry about the reliability of these things. Relying on the compiler for syntax errors is usually a plus, but here's a snippet of what the syntax might look like: -- Use square bracket quote for block string sources = [[ simpleLib.cxx simpleCLib.c simpleWe.cpp ]] Then something has to be written to parse this string, presumably a split on whitespace type thing (but what about filenames with spaces? Bleh) One suggestion, I personally like using a nested table to give functions namespaces. So instead of cm_add_library, you could do cm.add_library. The standard Lua libraries do this (math., table., io.,). There are a whole bunch of documented tricks users can then apply to simulate 'using namespace' and so forth. On #include lua.h, because Lua can be placed anywhere (lua, lua50 lua51, lua5.1, etc), I recommend #include lua.h with a robust FindLua.cmake module. (FYI, I on OS X, I have a framework.) I remember somebody was working on one, and I was supposed to submit mine which I have been lagging on, but it basically tries to deal with a lot of this. One of the tricky parts though is how to deal with the Lua standard library. Pre-5.1, it was traditionally a separate library while post 5.1 it is often rolled together. But either way, people can (de)bundle them. But if you embed Lua, this problem goes away. (Also, every non-patch version of Lua reserves the right to break the API/ABI so this is a secondary problem not bundling Lua has to deal with.) Assuming Lua does become a permanent component, then embedding Lua is easy enough and shouldn't impact the CMake build process much. Lua is small and compiles fast (especially compared to the CMake core). The Lua core is 100% ANSI C and purposely keeps a lot of platform specific stuff out so it is really easy to build on any platform. Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake with Lua Experiment
- The source code seems to have been crappified by windows. There's missing +x permissions on executable files and cr-lf linefeeds everywhere. Yup, just a quick zip of what is on my disc which is windows hence the CR/LF etc. - The source does: #include lua.h but the bootstrap/cmakelists.xt does not search for paths to it. Under my Ubuntu box, lua.h is located in lua5.1/lua.h or lua5.0/lua.h, not under the main /usr/include. Yeh. My bad. I either need to remove it from the bootstrap or support it in the bootstrap then that error should go away. For the regular cmake build (aka post bootstrap/windows) it is in the tree so it is easy. - The approach of a single cmCommand.cxx to parse functions is probably limiting as it makes it harder to make the command syntax more flexible. The LuaFunction is an ivar and can be overridden in subclasses. This is how I made get_property a function that returns a value. See cmGetProperty.cxx for an example of this. Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake with Lua Experiment
I doubt seriously we will adopt a second language in CMake. There is no question of maintaining the current language. It has to and will be kept in CMake. It was very easy to add Lua to CMake which is nice (literally it was probably 15 hours of effort). Part of this experiment was to see if it was even programtically practical to add a second language. It turns out it is. Doing a complete nice integration would be pretty easy except for variables and syntax. That is where the two approaches significantly differ and as others have posted that is one place where CMake currently does not scale well. For those of us accustomed to functions and local variables the macro command is not quite right. We do need to address the variable/scope issue in CMake and I am sure we will. Starting from scratch I would use Lua for all the benefits a mature language provides, but adding it (or transitioning to it) I *suspect* is not worth it. (although part of me thinks in the long ten-year-out view it is worth it) Sometimes these issues take a while to gel. Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 11:35 AM, Ken Martin [EMAIL PROTECTED] wrote: I doubt seriously we will adopt a second language in CMake. There is no question of maintaining the current language. It has to and will be kept in CMake. It was very easy to add Lua to CMake which is nice (literally it was probably 15 hours of effort). Part of this experiment was to see if it was even programtically practical to add a second language. It turns out it is. Doing a complete nice integration would be pretty easy except for variables and syntax. That is where the two approaches significantly differ and as others have posted that is one place where CMake currently does not scale well. For those of us accustomed to functions and local variables the macro command is not quite right. We do need to address the variable/scope issue in CMake and I am sure we will. Starting from scratch I would use Lua for all the benefits a mature language provides, but adding it (or transitioning to it) I *suspect* is not worth it. (although part of me thinks in the long ten-year-out view it is worth it) Sometimes these issues take a while to gel. Sounds like me arguing with myself about whether I could adopt a dog. Oh I live in a tiny apartment. Well that didn't turn out to be important. I think the syntax for any CMake embedded language has to handle variable length input. Lists of stuff are so common in a build system that the language should handle them gracefully. I don't know enough about Lua to know whether this is natural in it. It's definitely not natural in C++ and I wouldn't choose C++ for specifying a build system. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 26, 2007 3:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
I noticed the unpack command.
sources = {
simpleLib.cxx,
simpleCLib.c,
simpleWe.cpp
}
cm_add_library (simpleLib, STATIC, unpack(sources));
Would this be necessary / paradigmatic in Lua? In CMake I just use lists.
Reading the Lua docs, it seems one uses a table instead of a list.
There's a shorthand for calling a function that has 1 table as its
argument: f{whatever} instead of f({whatever}). So I think the above
could have been:
cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp}
and of course the function would have to handle the table
appropriately. Now I'll see if we can get rid of all those pointless
quotes.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 2:32 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
On Nov 26, 2007 3:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
I noticed the unpack command.
sources = {
simpleLib.cxx,
simpleCLib.c,
simpleWe.cpp
}
cm_add_library (simpleLib, STATIC, unpack(sources));
Would this be necessary / paradigmatic in Lua? In CMake I just use lists.
Reading the Lua docs, it seems one uses a table instead of a list.
There's a shorthand for calling a function that has 1 table as its
argument: f{whatever} instead of f({whatever}). So I think the above
could have been:
cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp}
and of course the function would have to handle the table
appropriately.
Lua also has a varargs interface via ... so there's no reason this has
to be done with a table. But I guess you knew that already. So, the
real wart is that in CMake we only have to type ${sources} and in Lua
we'd have to type unpack(sources) all the time. That's gonna get old.
Now I'll see if we can get rid of all those pointless quotes.
It doesn't look possible. That's annoying.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Brandon Van Every wrote:
On Nov 27, 2007 2:32 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
On Nov 26, 2007 3:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
I noticed the unpack command.
sources = {
simpleLib.cxx,
simpleCLib.c,
simpleWe.cpp
}
cm_add_library (simpleLib, STATIC, unpack(sources));
Would this be necessary / paradigmatic in Lua? In CMake I just use lists.
Reading the Lua docs, it seems one uses a table instead of a list.
There's a shorthand for calling a function that has 1 table as its
argument: f{whatever} instead of f({whatever}). So I think the above
could have been:
cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp}
and of course the function would have to handle the table
appropriately.
Lua also has a varargs interface via ... so there's no reason this has
to be done with a table. But I guess you knew that already. So, the
real wart is that in CMake we only have to type ${sources} and in Lua
we'd have to type unpack(sources) all the time. That's gonna get old.
Now I'll see if we can get rid of all those pointless quotes.
It doesn't look possible. That's annoying.
How about?
cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
Regards,
Juan
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake with Lua Experiment
Quoting Ken Martin [EMAIL PROTECTED]: I doubt seriously we will adopt a second language in CMake. There is no question of maintaining the current language. It has to and will be kept in CMake. It was very easy to add Lua to CMake which is nice (literally it was probably 15 hours of effort). Part of this experiment was to see if it was even programtically practical to add a second language. It turns out it is. Doing a complete nice integration would be pretty easy except for variables and syntax. That is where the two approaches significantly differ and as others have posted that is one place where CMake currently does not scale well. For those of us accustomed to functions and local variables the macro command is not quite right. We do need to address the variable/scope issue in CMake and I am sure we will. Starting from scratch I would use Lua for all the benefits a mature language provides, but adding it (or transitioning to it) I *suspect* is not worth it. (although part of me thinks in the long ten-year-out view it is worth it) Sometimes these issues take a while to gel. Just to make it totally clear as I was the one who tell you off: if the future of CMake is Lua, then I am totally in and for it. But in that case, please, please remove the current language. Every time someone creates a new Linux distribution, database engine or programming language to unify them all, it's a new one I have to learn and support. About regular expressions, I have started an implementation of regular expressions using PCRE 7.4 and the official PCRE C++ bindings (the ones contributed by Google last year). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Tuesday 27 November 2007, Juan Sanchez wrote:
...
How about?
cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
Are you sure putting it all in one quoted string will make getting the quoting
right simpler than it is now ?
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Alexander Neundorf wrote:
On Tuesday 27 November 2007, Juan Sanchez wrote:
...
How about?
cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
Are you sure putting it all in one quoted string will make getting the
quoting
right simpler than it is now ?
Please remember the context:
On Nov 27, 2007 2:32 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp}
.
.
.
.
Now I'll see if we can get rid of all those pointless quotes.
I was specifically talking about the lua api and offer suggestions
concerning Brandon's dislike for quotation marks and commas. Of course
cmake's current language is simpler. The goal of course is to have a
language which is well documented, popular, self-consistent, and not
home-made.
Of course, I'd much prefer Tcl, but everyone else hates it. However, if
Lua takes off, it will be much better than what we have now.
Juan
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Brandon Van Every wrote:
On Nov 27, 2007 3:22 PM, Juan Sanchez [EMAIL PROTECTED] wrote:
How about?
cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
That paradigm is crippled with respect to FOREACH and LIST style
processing. I can't really see everyone on the CMake script side of
things doing it one way, and the Lua side of things doing it another
way. Plus it doesn't help for strings within strings.
I'm starting to realize that general purpose programming languages
don't care about ease of string entry. Whereas shell / make / build
tools have a history of making strings easy at the expense of other
programming constructs.
The reason I suggested Tcl was it makes strings easy. Most everything
is a string in Tcl. There are also no commas, parenthesis, or quotation
marks. Everyone hates Tcl, and I accept that.
For those of you who don't know enough about Tcl to hate it, please
check out:
http://en.wikipedia.org/wiki/Tcl#Syntax
My only desire is that we move on to another language better than the
one we have now. Lua seems to fit the bill.
Juan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 3:50 PM, Juan Sanchez [EMAIL PROTECTED] wrote: The goal of course is to have a language which is well documented, Yep. popular, Or at least not unpopular. There's a perception that TCL has lost the scripting wars. self-consistent, Yep. and not home-made. Well, there are quality and maintenance tradeoffs here. Someone else's language ain't that great if it's a PITA to use. if Lua takes off, it will be much better than what we have now. I'm not convinced. I'd like to see an acutal Lua build system, to get an idea just how many quotes and unpack() statements I'd likely be typing. Googling... Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007, at 4:08 PM, Brandon Van Every wrote: On Nov 27, 2007 3:50 PM, Juan Sanchez [EMAIL PROTECTED] wrote: The goal of course is to have a language which is well documented, Yep. popular, Or at least not unpopular. There's a perception that TCL has lost the scripting wars. self-consistent, Yep. and not home-made. Well, there are quality and maintenance tradeoffs here. Someone else's language ain't that great if it's a PITA to use. if Lua takes off, it will be much better than what we have now. I'm not convinced. I'd like to see an acutal Lua build system, to get an idea just how many quotes and unpack() statements I'd likely be typing. Googling... Cheers, Brandon Van Every How about we give the cmake developers some time to address some of the shortcomings of CMake BEFORE we toss the baby out with the bath water... -- Mike Jackson Senior Research Engineer Innovative Management Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
At 11/27/2007 04:02 PM, Juan Sanchez wrote: The reason I suggested Tcl was it makes strings easy. Most everything is a string in Tcl. Everything is a string in Tcl :) I'm not a Tcl noob, and things are not *that* easy in Tcl: when you have to throw an eval now and then, you know someone else is going to be in trouble understanding that code. There are also no commas, parenthesis, or quotation marks. Everyone hates Tcl, and I accept that. We don't hate Tcl at Kitware, we have been using Tcl for a long long time actually. VTK, our first (and probably largest) OpenSource product was wrapped pretty early on for that language (before Python or Java), and it was a satisfying experience; I remember prototyping VTK projects using Tcl almost 10 years ago, good times. We actually still rely heavily on Tcl/Tk for newer projects like KWWidgets (http://kwwidgets.org), we are compiling/rolling on own Tcl/Tk distrib internally every night for more than a few commercial products, and most of our testing is done in Tcl. See. Bill Hoffman said it last week: we have plenty of experience with Tcl, and it was specifically avoided in CMake from the start, probably for that reason :) This is way too big of a dependency for a build system like CMake. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 4:02 PM, Juan Sanchez [EMAIL PROTECTED] wrote: My only desire is that we move on to another language better than the one we have now. Lua seems to fit the bill. Just realized an interesting argument *not* to use an off-the-shelf language. Over the long haul, you lose control over the installed base. From the SCons FAQ: http://www.scons.org/faq.php#SS_3_6 3.6. Why is SCons written for Python version 1.5.2? Python 1.5.2 is still in widespread use on many systems, and was the version shipped by Red Hat as late as Red Hat 7.3. By writing the internal code so that it works on these systems, we're making it as easy as possible for more sites to install and work with SCons on as wide a variety of systems as possible. Why don't people just upgrade their Python version? you may ask. Yes, Python's packaging and installation make it easy for people to upgrade versions, but that's not the only barrier. In commercial development environments, any new operating system or language version must usually be accompanied by extensive tests to make sure that the upgrade hasn't introduced subtle problems or regressions into the code being produced. Consequently, upgrading is an expensive proposition that many sites can't undertake just because a new tool like SCons might require it. When faced with that sort of choice, it's much less risky and expensive for them to just walk away from trying the new tool. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 4:25 PM, Mike Jackson [EMAIL PROTECTED] wrote: How about we give the cmake developers some time to address some of the shortcomings of CMake BEFORE we toss the baby out with the bath water... Sounds good to me. Let's see where CMake is 6 months from now, with respect to scoping and documentation. While ruminating over Lua, I ran into cmake-promote arguments about Lua from almost 2 years ago. Something about a Lua front end for SCons called Hamster. Well, it's 1 guy's effort, it's GPLed, and the project page doesn't have any online documentation. CMake may be lacking in some areas, but it's worth considering where the competition is at. So I went to SCons to try to find the old SCons vs. everybody else page, and I found the bit in the FAQ about it being based on Python 1.5.2. I wonder if SCons loses Pythonistas because it uses an old Python? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
are a little different. If CMake adopts Lua, then it should be embedded with CMake (especially since it is not standard with Windows and Mac). Because you embed Lua, the CMake authors have complete say on which version is used and is not influenced by what the most popular Linux distro has installed and is available to the masses. So CMake has final discretion over which version is used. As for the Lua community, I wouldn't expect abandonment if you froze on Lua 5 while a hypothetical Lua 6 was very mature. However, you may hear lots of requests to upgrade if there was a new killer language feature that made things easier. But as merely a scripting API to CMake, I wouldn't expect there to be many language features that are invented that most users would care about. More likely I think, the CMake authors will see something new in the Lua-C API that makes things easier and they might want to upgrade. And I would say to most outsiders, seeing Lua 5 used instead of Lua 6 is still a much less significant deal than users having to worry about learning CMake script and also dealing with their own version changes (1.8 vs 2.0 vs 2.2 vs 2.4 etc). ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 10:13 PM, E. Wing [EMAIL PROTECTED] wrote:
I think you are misinterpreting some things about the Lua syntax.
My understanding of Lua syntax improved greatly after reading the
docs for 15 minutes.
Or we could exploit the varargs capability and not even use a table
and just list things one by one:
cm_add_library( simpleLib, STATIC, simpleLib.cxx,
simpleCLib.c, simpleWe.cpp)
The programmer desired to use a variable. In CMake script we would write
add_library(simpleLib STATIC ${sources})
This is actually what unpack(sources) was doing. Unpack was basically
flattening/unpacking the table and passing each element in the table
as a separate parameter.
(Aside: what's with the cm_ prefix?) In Lua we could write:
add_library(simpleLib, STATIC, unpack(sources))
I consider the quoting and the unpack() to be more verbose. The
commas don't bug me, I think because I don't have to hit SHIFT to type
them.
Lua's varargs ability automatically kicks in
and unrolls the thing. 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. Pretty unreasonable for a language to
treat a variable representing a table, and the expansion of the table,
as exactly the same thing. In CMake script, a LIST and a ${LIST} are
not the same thing.
That paradigm is crippled with respect to FOREACH and LIST style processing.
I'm not completely sure what you are after here, but Lua also has a
for/foreach construct for tables so you can use that too.
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.
3.6. Why is SCons written for Python version 1.5.2?
That's an interesting and legitimate point. With Lua, though, the
issues are a little different. If CMake adopts Lua, then it should be
embedded with CMake (especially since it is not standard with Windows
and Mac). Because you embed Lua, the CMake authors have complete say
on which version is used and is not influenced by what the most
popular Linux distro has installed and is available to the masses. So
CMake has final discretion over which version is used.
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.
An additional thought is to export global constants (variables), so we
can basically create keywords. So instead of:
cm_add_library( simpleLib, STATIC, sources)
we could drop the quotes around STATIC:
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. But it would still be 95% the
same, and Lua quotes would work as documented... you just wouldn't
always need them. Most of the marketing value of Lua would be
retained. And that marketing value isn't permanent anyways. Only
drawback I see, is I suppose quoteless Lua strings might bugger third
party Lua libraries, unless some nice marshaling to external libraries
is possible.
If Lua has some kind of preprocessor, it would be trivial to regex the
input file for certain string types, then add the quotes to keep Lua
happy. If it can't be done then throw an error about lack of quotes.
The docs would have a teeny tiny addendum to describe the Lua dialect.
Such mods shouldn't be culturally verboten to Lua people anyways.
It's supposed to be an embeddable and customizable language.
(We also might consider namespacing the keywords: CM.STATIC.)
No. It's a build system and Lua is the embedded language to serve the
build system. That's the context for anything anyone is ever gonna
do. The cm_ prefixes should go bye-bye. Constants in CMake script
should be exactly the same as constants in Lua script. It should be
trivial for a CMake script veteran to pick up CMake Lua, and wherever
possible, it shouldn't give the CMake script veteran a rash. It
should be an obvious and desireable migration path; otherwise, what's
Re: [CMake] CMake with Lua Experiment
Hi CMakers! Being relatively new to CMake (3 months now), this whole LUA discussion seems very odd ... (so please accept an apology for my ignorance in advance) An additional thought is to export global constants (variables), so we can basically create keywords. So instead of: cm_add_library( simpleLib, STATIC, sources) we could drop the quotes around STATIC: cm_add_library( simpleLib, STATIC, sources) Maybe I am missing the obvious, but I am trying to understand -why- this list is talking about replacing the current CMake language. As it seems everyone is trying to retrofit the would be new language to be just like the current language. I do understand the want (need?) to retain backwards compatibility, but a fork-lift replacment of the current language sounds like a bad idea; if that is indeed the goal. Thanks, George. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
