Re: [CMake] CMake and Lua
On Sunday 02 March 2008, Timothy M. Shead wrote: > On Sat, 2008-03-01 at 15:20 -0500, Brandon Van Every wrote: > > > * no well defined syntax: > > > > > > - missing datatypes; all seems to be a string. Mastering ';' and > > > spaces is trial-and-error game :( > > > > Totally agree on this point. It needs documentation. My suggestion > > on the matter is http://cmake.org/Bug/view.php?id=6295 "Document core > > syntax in a chapter format." Feel free to add your comments there. > > An excellent start can be found at > > http://kernigh.pbwiki.com/CMake > > ... perhaps the author could be encouraged to contribute to the CMake > wiki directly. I added a link to his site to the cmake wiki 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
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 > > > > 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 => 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
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
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
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
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
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
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
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
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: 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
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
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
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 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/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 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
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? 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. Actually I pointed out that you did metaprogram in CMake (in a sarcastic way). I thought it was a bad idea, but if you did it, there might be others. I am sure there are several other issues that will come up as well. I just don't have the time 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. 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. 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. I have a gut feeling that you are wrong. I have never seen a perfect translation from one language to another. Can you give me an example of one that exists? BTW, You have no idea if you were 1/2 there or not, because you quit. 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. -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
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 9:53 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > 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... That's my point. It's an extreme corner case that I seriously doubt anyone's worried about. > But even if they > did, I would not want to invalidate there effort by obsoleting the > language they programmed in. 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. > >> 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. It's 2x work for the community. > 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. What's stopping you from putting if(IMPORTANT_BUT_STUPID_APP) code in CMake, if some CMake user is so important? What's stopping them from doing it? This is open source. Microsoft was intervening on behalf of extremely popular proprietary apps. They certainly didn't intervene on behalf of no-names, such apps had to break and follow the new rules same as everyone else. > 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! *Software* doesn't work for 100% of the cases. > You of all people should realize that. The article you quoted above cites plenty of examples of Microsoft importing old data silently and correctly, until a certain point in their history. I'm not seeing this big problem with CMake script --> Lua translation that you're glooming and dooming about. Need I remind you that CMake is a trivial language? Automake + GMake --> CMake is much harder, it's got lotsa weird $< variables and $(call blah) operators and general shell programming going on. > However, supporting both languages is an option. It's good that you think so. I don't think that was your position a few months ago. I still think migrating to a new paradigm is better than supporting 2 paradigms indefinitely. > Also, please refrain from calling me a liar. > There are no hidden motives or invented excuses. > You may not agree with me, but that does not mean I am inventing > excuses. 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 software. In open source, these are not insoluble problems. I'm rather stability minded. I talked about automated translators proving themselves for 2 years before dumping CMake script. That's a high bar to meet. I say, if a bar can be met, then move on. Most commercial applications behave this way. They don't maintain old file formats forever, they expect you to run them through their translators. > If this is how you treated the Chicken maintainer, he may have > dropped CMake just to get you off his mailing list 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. That doesn't apply to our discussion here. What does apply: you made a snarky comment about the unprovability of whether things work 100%. It's a comment that invites resistance. Why should unprovability be the end of an engineering discussion? Most things we do as programmers are not proven in practice. We may write test cases and prevent a lot of things, but we also have mailing lists and bug trackers. We expect to do work. The question is how much work; we aren't owed zero work indefinitely. > 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. That's encouraging. > 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. That's good to hear. I think I've been pretty objective about Lua. I
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
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
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 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: 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 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
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
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
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
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
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 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: 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: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
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
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
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'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
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
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
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
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
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
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
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 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
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-l&m=120275861422593&w=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 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-l&m=120275861422593&w=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
> 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
> 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
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
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 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 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 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
> 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
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
