Re: [CMake] improve the CMake language?
Brandon Van Every wrote: 1) licenses that are unfriendly to unfettered commercial development, often don't get accepted by commercial developers. Not really. cmake is a stand-alone utility. With any of the scripting language licenses, you can still ship cmake with your own, say, proprietary non-open source IDE. For a utility like cmake that has very little use outside development, licensing is not going to be the main issue in making it more or less popular. The main reason will be how good it is (or isn't). If cmake was a popular C library on the other hand... the type of OSI licensing would indeed matter *much* more. 2) I don't personally make a habit of investing in software that encumbers me. MIT / BSD / zlib-libpng licenses allow me... Right... I'll let it slide that your main platform of development is Windows. And I agree with Juan, Lua sounds more compelling than Ruby. Brandon, my understanding is that you don't know neither ruby nor lua. Before you make that kind of statement, you actually might want to spend some time actually using both languages first. 3) Your license choices are fine for your own use, but you'd need to talk to Kitware about what they actually want. Now, that could be a fair point. If I was interested in having Kitware distribute cmake with ruby. Which albeit I like the idea, I don't think I pushed for it. As I said, I'm more interested in having a cmake have a language API or swig wrappings. That way, I don't really have to make a commitment to a scripting language that can fall out of flavor later on. I'd also rather offer people several options and let the best language arise naturally from that choice. SWIG allows you to do that with the least pain, even if the project is under heavy development like cmake. Also, you guys are just thinking of embedding the language into cmake. I think it is much easier (and less of a license trouble) to do the opposite. Make cmake a *library* to the scripting languages. That is (for ruby): require 'cmake' include CMake generator = 'Unix Makefiles' cxx_flags = -W 3 sources = %w( hello.cpp ) add_executable( :hello, :sources = sources ) run Sure. That's from your POV. For me, a language without good and easy OO is a no-no as experience tells me it will sooner or later run into scalability and maintainability issues. That makes TCL and Lua to me only minimally better than cmake's language in the long run. What's the biggest build system you've yet written? Biggest, a custom one for a now defunct company. Better one? Industrial Light and Magic's. Albeit I did not build it myself. I was more or less consultant and beta tester for it. cmake's source code in terms of .cmake files is already at the tipping point of begging for OO. The main ./configure Err... by your own standard, you can't use that. That is GPL only. It's not an exotic OO exercise; that would be a waste of time. If you think OO is a waste of time and not a way to reduce your 400Mb of source code into probably 70Mb or less and enforcing consistency and readability, well... Well that doesn't sound like the dumbest technical trick I've heard. Could it help with parallel builds? Nope. Parallel builds in cmake are handled by your make program, not cmake. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Nov 8, 2007 12:10 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Anyway... why are you guys so concerned about cmake's license? To me, as long as the code is open source and forkable, that's all I care for cmake. I'm not planning to make money selling a fork of cmake, borrow its source code, use cmake as a library nor embed it into another program, which are the reasons I might prefer a BSD/MIT license. 1) licenses that are unfriendly to unfettered commercial development, often don't get accepted by commercial developers. They don't have time for the FUD of multiple license holders or you can do this but can't do that clauses. To the extent that I want CMake to be very very popular, I don't want the license getting in the way. 2) I don't personally make a habit of investing in software that encumbers me. MIT / BSD / zlib-libpng licenses allow me to do whatever I want with the code. So long as I have choices, I prefer to keep my options open. And I agree with Juan, Lua sounds more compelling than Ruby. 3) Your license choices are fine for your own use, but you'd need to talk to Kitware about what they actually want. Sure. That's from your POV. For me, a language without good and easy OO is a no-no as experience tells me it will sooner or later run into scalability and maintainability issues. That makes TCL and Lua to me only minimally better than cmake's language in the long run. What's the biggest build system you've yet written? Right now I'm messing with one that's 400MB of source code. The main ./configure file is 240K, pretty long and piggish. But it's still just a big long dumb file, something I can eyeball. It's not an exotic OO exercise; that would be a waste of time. I don't claim tremendous experience at huge build systems, but I think it would need to be 4GB of source before I started thinking gosh, I really could use some OO. And I don't think I'd be working on such a thing by my lonesome either. The build I'm currently working on is still graspable by 1 person, even if it's a pig of a job to convert to CMake. TCL and Lua are only better for embedding if you were to need cmake to be multithreaded Well that doesn't sound like the dumbest technical trick I've heard. Could it help with parallel builds? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Gonzalo Garramuño wrote: 3) Your license choices are fine for your own use, but you'd need to talk to Kitware about what they actually want. Now, that could be a fair point. If I was interested in having Kitware distribute cmake with ruby. Which albeit I like the idea, I don't think I pushed for it. As I said, I'm more interested in having a cmake have a language API or swig wrappings. That way, I don't really have to make a commitment to a scripting language that can fall out of flavor later on. I'd also rather offer people several options and let the best language arise naturally from that choice. SWIG allows you to do that with the least pain, even if the project is under heavy development like cmake. Also, you guys are just thinking of embedding the language into cmake. I think it is much easier (and less of a license trouble) to do the opposite. Make cmake a *library* to the scripting languages. That is (for ruby): require 'cmake' include CMake generator = 'Unix Makefiles' cxx_flags = -W 3 sources = %w( hello.cpp ) add_executable( :hello, :sources = sources ) I guess I can speak for Kitware here. We have very little interest in maintaining CMake as a library. It is just too much work. There is a big difference between maintaining an executable, and a library. Backwards compatibility becomes a much bigger problem as the API becomes much bigger if you expose the library as part of the API. Also, I am not sure having N languages for CMake would be the best approach. So, you go to build a project, and hey they are using CMake, cool, I know how to run CMake, oh wait, that one is ruby CMake, I need to get the ruby CMake to build it. Would Kitware have to distribute N binaries? One of the biggest complaints about CMake, is that it requires CMake to be installed in order to do the build. What if it required N different binaries where N was decided on by the project doing the build. I just don't think that would be in the best interest of the community. At the end of the day CMake should be like make, it should be a binary utility that is available by default on every OS. It is a single interface so that if you know how to use it in one place you can use it in another. -Bill -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On 11/8/07, Bill Hoffman [EMAIL PROTECTED] wrote: Gonzalo Garramuño wrote: [...] Also, I am not sure having N languages for CMake would be the best approach. So, you go to build a project, and hey they are using CMake, cool, I know how to run CMake, oh wait, that one is ruby CMake, I need to get the ruby CMake to build it. Would Kitware have to distribute N binaries? One of the biggest complaints about CMake, is that it requires CMake to be installed in order to do the build. What if it required N different binaries where N was decided on by the project doing the build. I just don't think that would be in the best interest of the community. At the end of the day CMake should be like make, it should be a binary utility that is available by default on every OS. It is a single interface so that if you know how to use it in one place you can use it in another. I totally agree with this point. The least I want is to have to configure/build the build system before I get to the actual project. That, from my POV, also applies to the 'language as a plugin to cmake' approach, as one may not have the appropriate plugin to build project X, and has to download/built it from svn etc. I feel this is way more pain in the long run than being stuck with a particular programming language. -Bill -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Thursday 08 November 2007, Mike Jackson wrote: ... As a user of CMake let me second this notion also. CMake only depends on a C++ compiler which is every where. Tying CMake to Ruby, Perl, tk or anything else may actually decrease CMake's market penetration. I don't really see Ruby running on a Cray but CMake will. Running ruby on the compute nodes of a cray would make much more sense than running cmake on the compute nodes of a cray (... and it shouldn't be too hard, actually) ;-) I have the slight feeling that this is getting a bit OT... Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Nov 8, 2007 7:01 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: If cmake was a popular C library on the other hand... the type of OSI licensing would indeed matter *much* more. What if I just want to rip a chunk of code out of Ruby and reuse it somewhere? I'll have the PITA of carrying the entire original Ruby with me. 2) I don't personally make a habit of investing in software that encumbers me. MIT / BSD / zlib-libpng licenses allow me... Right... I'll let it slide that your main platform of development is Windows. Show me a larger game market with fewer restrictions on the indie game developer. And I agree with Juan, Lua sounds more compelling than Ruby. Brandon, my understanding is that you don't know neither ruby nor lua. Before you make that kind of statement, you actually might want to spend some time actually using both languages first. I've watched Lua vs. Ruby in the game industry for many years. 3) Your license choices are fine for your own use, but you'd need to talk to Kitware about what they actually want. Now, that could be a fair point. If I was interested in having Kitware distribute cmake with ruby. Which albeit I like the idea, I don't think I pushed for it. As I said, I'm more interested in having a cmake have a language API or swig wrappings. The last time we had a language API debate, Kitware said no way. Check the archives. My $0.02: where's the profit in it? Doing a lot of work to entertain everyone's pet language agenda isn't core to building software. Mr. Miyagi in The Karate Kid said something along the lines of better to know 1 kick well. That way, I don't really have to make a commitment to a scripting language that can fall out of flavor later on. I don't know what you're worrying about. Python and Lua are here to stay, they've proven themselves in their domains. I'd be surprised if Ruby's going anywhere, unless Perl 6 finally ships and destroys it somehow. Seems pretty low odds of that happening, seems like Ruby's already inherited the Perl 6 audience. TCL is on the wane which is why I'm against TCL. CMake doesn't need the negative perceptions; in particular, it doesn't need to look like old software. Anyways, if we choose a popular scripting language today, it's going to be 10 years before the sun sets on it. By then, it's about whether CMake has cemented itself in the popular consciousness, not the scripting language. Also, you guys are just thinking of embedding the language into cmake. I think it is much easier (and less of a license trouble) to do the opposite. There isn't any license trouble with Python or Lua. Make cmake a *library* to the scripting languages. That is (for ruby): Great, now they need a Ruby installation to use CMake in this manner. We're not on the same page about the goals. What's the biggest build system you've yet written? Biggest, a custom one for a now defunct company. Better one? Industrial Light and Magic's. Albeit I did not build it myself. I was more or less consultant and beta tester for it. ILM is one of the crown jewels of the Python Success Stories. http://pythonology.org/successstory=ilm What did they need the OO for? And, given they did great with Python, why would they have been better off doing it in Ruby? cmake's source code in terms of .cmake files is already at the tipping point of begging for OO. Dunno. I'll let others debate that one, as I'm not that familiar with CMake's code base. I just poke at it when I need to know something about bugs or how CMake works, I haven't contributed to it in any way. We all agree that CMake script needs some kind of scoping. That's been decided and the wheels are turning on it. But OO? Dunno. The main ./configure Err... by your own standard, you can't use that. That is GPL only. I don't use Autoconf or GMake. I translate them to CMake. It's not an exotic OO exercise; that would be a waste of time. If you think OO is a waste of time and not a way to reduce your 400Mb of source code into probably 70Mb or less and enforcing consistency and readability, well... Oh, the 400MB is mostly a pile of C++ and Java code. The build system is not. It's about 1200 trivial Makefiles, about a dozen substantial Makefiles, and one big honkin' ./configure script. This isn't my code, I'm merely translating the build system to CMake. And I'm saying, it's big and flat, it doesn't need OO. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Juan Sanchez wrote: I was reading exactly the link you sent, and the same one you accused Brandon of not reading. If there were supplemental materials, you should have sent them. I am not a lawyer. To Juan: Yes. The best place for any license question about source code is, as usual, the source code. In ruby's case, its source code is in SVN at: svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby1.9 That's where you will find LEGAL which has probably the most up to date status of each file not entirely written by the ruby team. If you need further clarification about a source file, you should ask probably in the ruby-core's mailing list. Also, this is only about the (most popular and currently faster) C Ruby we are talking about. There's several other ruby interpreters which are under other licenses. To Brandon: Sorry, yes, that was a mistype. I really meant Ruby is dual licensed as GPL and its own license. Anyway... why are you guys so concerned about cmake's license? To me, as long as the code is open source and forkable, that's all I care for cmake. I'm not planning to make money selling a fork of cmake, borrow its source code, use cmake as a library nor embed it into another program, which are the reasons I might prefer a BSD/MIT license. To be honest, the only compelling languages I've seen so far in this discussion is lua and tcl. This is because they are small and appear to be ideal for embedding. Sure. That's from your POV. For me, a language without good and easy OO is a no-no as experience tells me it will sooner or later run into scalability and maintainability issues. That makes TCL and Lua to me only minimally better than cmake's language in the long run. For me, I would accept either Python or Ruby as a better alternative, even if they are not as small. TCL and Lua are only better for embedding if you were to need cmake to be multithreaded or if cmake would need to initialize a clean interpreter without quitting (two things, afaik, not needed or currently used in cmake). Otherwise, there's not much difference with embedding Ruby, Python, etc. Perl is the only language I would say that has a very difficult API for embedding. Not that speed is super important, but I know of at least one hosting provider making exceptions for ruby scripts, because they just take way too long to run. That's pretty funny. Ruby (1.8) scripts run about the same speed as TCL (ie. neither one is known to be a speed daemon). Ruby1.9 (to become the official ruby in 2008) runs at about the speed of Python (ie. much better than TCL). Lua is certainly a faster language in terms of VM and numeric computations. But for io, string, regex, etc. you are not likely to see a big difference. The next link is *very* un-scientific and I don't endorse it. But it is still an okay website to at least give you a very rough idea of performance: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=alllang=yarvlang2=python -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
I was reading exactly the link you sent, and the same one you accused Brandon of not reading. If there were supplemental materials, you should have sent them. I am not a lawyer. To be honest, the only compelling languages I've seen so far in this discussion is lua and tcl. This is because they are small and appear to be ideal for embedding. Not that speed is super important, but I know of at least one hosting provider making exceptions for ruby scripts, because they just take way too long to run. Juan Gonzalo Garramuño wrote: Sanchez, Juan wrote: This part of the license would concern me. Are all files of interest, by other authors, guaranteed to be BSD friendly? Again, read LEGAL. You will then find that: regex when used with Ruby it is Ruby licensed, based on Onigurama. utils is BSD, credit going to Lucent Technologies. gcis Public Domain (Boehmm), albeit now is so heavily modified there's no resemblance to it any longer (probably the docs need updating). stis Public Domain. Other files may use Perl's Artistic License. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Sanchez, Juan wrote: This part of the license would concern me. Are all files of interest, by other authors, guaranteed to be BSD friendly? Again, read LEGAL. You will then find that: regex when used with Ruby it is Ruby licensed, based on Onigurama. utils is BSD, credit going to Lucent Technologies. gcis Public Domain (Boehmm), albeit now is so heavily modified there's no resemblance to it any longer (probably the docs need updating). stis Public Domain. Other files may use Perl's Artistic License. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
For interest, this topic has been brought up before. http://public.kitware.com/pipermail/cmake-promote/2005-December/39.html ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Nov 7, 2007 8:55 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Sanchez, Juan wrote: This part of the license would concern me. Are all files of interest, by other authors, guaranteed to be BSD friendly? Other files may use Perl's Artistic License. That's the license I had read, that Ruby is like. The Artistic License. Kind of a PITA, frankly. I mean, yeah, you can put up with it if the software really really does something for you, but I'm not seeing what's so great about Ruby compared to other options to warrant jumping through the legal hoops. Seems like Ruby could stand a license assignment cleanup, so that people don't have to worry about needing an army of lawyers. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Ken Martin wrote: I have looked at incorporating Lua into CMake as an alternate language. Interesting. You didn't by any chance used swig to wrap it? I admit I would be curious to see that fork of cmake to study the changes. Using swig right now would be the best approach, as with just a few swig rules (if any) it would allow any user to choose whatever language he feels like using. Currently, swig supports all languages mentioned in this thread so far and it works pretty well for projects like cmake where its .h files keep changing. Eventually one scripting language could end up becoming massively more popular and be adopted as a standard for cmake. But I'm betting in the future that won't matter, as several vendors are developing tools or frameworks to offer data interchange across the major scripting languages. -- For those that don't know Lua, Lua has a very similar syntax to non-OO ruby albeit parenthesis are required. It is also very fast, small and, just like TCL, thread safe and built for embedding (python and ruby still struggle with threads). LuaJIT is probably one of the fastest JIT compilers for a dynamic language under any platform. Lua's uglyness is its OO support and syntax, which is closer to OO Javascript or Perl's. -- P.S. Disclosure: I am swig's ruby maintainer. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] improve the CMake language?
It is my understanding that a lot of the cmake modules are implemented in the cmake language? It would be a big task to maintain multiple languages for the cmake modules. While speed of a scripting language is interesting, I would expect 90% of the work would be done in the C++ part of cmake. I would think BSD type licensing and compactness would be more important. Juan -Original Message- From: [EMAIL PROTECTED] on behalf of Gonzalo Garramuño Sent: Mon 11/5/2007 4:55 PM To: Ken Martin; CMake ML; Sanchez, Juan Subject: Re: [CMake] improve the CMake language? Ken Martin wrote: I have looked at incorporating Lua into CMake as an alternate language. Interesting. You didn't by any chance used swig to wrap it? I admit I would be curious to see that fork of cmake to study the changes. Using swig right now would be the best approach, as with just a few swig rules (if any) it would allow any user to choose whatever language he feels like using. Currently, swig supports all languages mentioned in this thread so far and it works pretty well for projects like cmake where its .h files keep changing. Eventually one scripting language could end up becoming massively more popular and be adopted as a standard for cmake. But I'm betting in the future that won't matter, as several vendors are developing tools or frameworks to offer data interchange across the major scripting languages. -- For those that don't know Lua, Lua has a very similar syntax to non-OO ruby albeit parenthesis are required. It is also very fast, small and, just like TCL, thread safe and built for embedding (python and ruby still struggle with threads). LuaJIT is probably one of the fastest JIT compilers for a dynamic language under any platform. Lua's uglyness is its OO support and syntax, which is closer to OO Javascript or Perl's. -- P.S. Disclosure: I am swig's ruby maintainer. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Brandon Van Every wrote: I didn't realize that Ruby is GPLed. http://www.ruby-lang.org/en/LICENSE.txt Oh well, so much for embedding Ruby! It isn't. Where did you get that idea from !? Brandon, you have a tendency to email FUD that is amazing... even when you provide links to text that clearly states exactly the opposite of what you say. Ruby is distributed under a dual LGPL / Ruby License. The Ruby License is a MIT-like license. Some portions of ruby are not under that license (as they were not written by the author), but are either BSD (meaning you need to give proper credit) or public domain. For proper info, refer to LEGAL in the ruby distribution. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Nov 5, 2007 5:30 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Brandon Van Every wrote: I didn't realize that Ruby is GPLed. http://www.ruby-lang.org/en/LICENSE.txt Oh well, so much for embedding Ruby! It isn't. Where did you get that idea from !? Brandon, you have a tendency to email FUD that is amazing... even when you provide links to text that clearly states exactly the opposite of what you say. Hey man I was in a hurry, and at a glance, the Ruby license is clear as mud. I saw the word GPL at the top of that doc, and blasting through the license text I thought I saw the typical GPLed terms. I see now I was mistaken. I don't appreciate your indignation about FUD though; you're not paying me to go over licenses with a fine toothed comb. If people say things that are incorrect - or that you think are incorrect - you're free to correct them or disagree with them. You might also consider how you'd like people to react to your own mistakes. Clauses (2a 2b 3a 3b) are like a GPL, hence my confusion. Clauses (2d 3d) are a talk to the author escape hatch; a lot of people aren't going to do that. I see that clauses (2c 3c) give the do whatever you like freedom - long as you ship original Ruby along with your altered stuff. That is probably acceptable to a lot of people, but the bloat could be unacceptable for some embedded applications. Also sometimes people are contractually stuck with no viral license clauses as far as software they can use. Ruby is distributed under a dual LGPL / Ruby License. That link says GPL, not LGPL. The Ruby License is a MIT-like license. Hardly. MIT is a simple license. In addition to the complications above, clause (4) leaves one wondering about some of the core components. The Ruby license, when seen through the lens of do what you want, is like a more restrictive version of zlib/libpng. In fact I'm sure I've seen an OSI license of the form do what you want, but you must also ship the originals, but I can't remember the name of it. This isn't MIT / BSD. Is it acceptable for CMake embedding? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
From: Eric Noulard [EMAIL PROTECTED]: I used Java for 4+ years (all thoses years are overlapping :=) it was really pleased using it for cross platform GUI. And I was really disappointed because the java I used was lacking generics such that I need to cast here and there when using container. This may be a little off-topic, but generic types were added to Java at least two years ago. So, for example, you now can declare an object of type VectorString. Generic types are also useful for a lot more than just avoiding casts when getting objects from containers. I hope I've already put you on the road of there is no FAR better language than other. This is an excellent point. Unlike any specific language feature, this statement is not likely to be falsified by the language designers at any time in the near future. Personally, I find the macros of CMAKE a little awkward at times, but when I want to do anything more sophisticated, I am very happy to write a little helper script or program for CMAKE to invoke. I converted the build of one of my group's software projects to CMAKE a few years ago and it's served us very well ever since, though we now have more than 1800 source code files distributed among nearly 50 libraries and executables. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Eric Noulard wrote: CMAKE_LOAD_PLUGIN(TCL) CMAKE_TCL(IN_VAR a IN_VAR b OUT_VAR g OUT_VAR h SCRIPT_STRING any tcl code) or CMAKE_TCL(IN_VAR a IN_VAR b OUT_VAR g OUT_VAR h SCRIPT_FILE /path/to/tcl_script.tcl) You can do that today. CMake already supports loaded commands via c++ plugins. I would not recommend it, execute_process is much safer to use (shared library plugins have to match the compiler abi of the running cmake 64/32 bit issues can cause problems.) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Fri, 2 Nov 2007, Brandon Van Every wrote: On Nov 1, 2007 11:40 PM, Sanchez, Juan [EMAIL PROTECTED] wrote: Tcl is a simple language, and is well understood. It has already been ported to about every platform out there. You don't need QT or wxWidgets, because the Tk extensions of it already work. Tcl's popularity is also on the wane. I don't think hitching CMake's post to Tcl is a good marketing idea. I'd pick Ruby, for the regex support. Hey it's better 'n' Perl 6. :-) Many features in the CMake language don't really work the way people expect, or are not documented, or both. I agree that much can be improved about the documentation. I'd like to note, however, that some improvements are happening in CVS right now. Enough to make me think that Kitware does take documentation seriously and that strategically, documentation problems are going to be addressed. I've given a lot of gloom and doom about documentation, that if the status quo is maintained, in 3 years' time CMake will start to lose customers as other build systems catch up in technical capability. But I do think 3 years is the level of urgency of the problem. We'd all like things right this second, but open source has its resource limitations. Recently I suggested organizing Google Summer Of Code projects to address such things. If anyone would like to fork cmake with me, I'm game. Features: Tcl frontend featuring modern dynamic language constructs and consistent syntax. C pre-processor based dependency scanner Accurate and up to date documentation Focus on getting build system that works, because all of the language constructs have already been written. Developers who are not hostile to ideas concerning improvements to the language. To make real improvements in all of those areas, you'd need a lot of funding. What kind of mandate do you have? There's not much point in saying everything's gonna be better if you don't have the labor. Second question, if you do have serious development resources at your disposal: what improvements in CMake would cause you to stick around rather than going your own way? Is a position of compromise possible? This would be a community effort. I don't have the resources to strike out on my own. I like using cmake. The language is kind of a bitter pill for people in my organization to swallow. The most important item on my proposed feature list is the Tcl frontend. Juan Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Sanchez, Juan wrote: Hello Bill, add_library(foo SHARED foo.cxx) won't work. I meant it worked in the current cmake language, I know it does not work in tcl. Developers who are not hostile to ideas concerning improvements to the language. I am not hostile to ideas about improvements to the language, I am hostel to changing to a new language. The requirements are that we don't bring any new major dependencies other than a standard c++ compiler. Also, that we remain backwards compatible. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
re: [CMake] improve the CMake language?
On Nov 2, 2007 6:04 AM, Eric Noulard [EMAIL PROTECTED] wrote: Many features in the CMake language don't really work the way people expect, or are not documented, or both. Documentation is not as good as it should be but re-implementing something (either TCL, Python, Perl) won't make the documentation better. Actually for language syntax issues, which CMake certainly has, the documentation would become tremendously better. And Kitware wouldn't have to maintain that documentation at all. There would be a bazillion Python or Ruby examples to choose from out on the net. In another thread I've asked about adding PCRE. One of the main benefits I see in PCRE is it's well-documented, whereas the CMake regex engine is not. I agree that how to use this CMake function to do XYZ won't improve by re-implementing CMake in another language. It's an orthogonal problem. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Nov 2, 2007 9:04 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Brandon Van Every wrote: My concern is that if the status quo is maintained, CMake script will always be ugly to program with. Yes. No doubt about that. It is already uglier to program with than most modern scripting languages. Personally I think you need to see cmake as what it is: a tool to create makefiles. Not a scripting language. But I think this is the wrong idea from a marketing standpoint. Programmers are programmers. They don't care what they're programming. If you tell 'em to suck it up, they don't wanna hear it. They'll just go use something that's more pleasant to work with, if it exists somewhere. And if it doesn't, they'll write it! I don't see any inherent reason why Makefile programming has to be tons uglier than regular programming. It's just the historical accident of where the implementation is at. Sooner or later, someone's going to decide that Makefile programming doesn't have to suck. Then that Makefile language is going to become popular. It could be CMake, with a little planning. If you are doing lots of file, regex or string manipulation... alarms should be going off. You should probably write that as a small tool in ruby, perl or python and have cmake just call the command. Yes I probably should have written my (Autoconf + GMake) -- CMake translator in Ruby. But I didn't know Ruby and I did know CMake script. I wanted to see how far I could get with CMake regexes and macro constructions, and I found out. You know, frankly, I could get a lot farther with some pretty basic language improvements. Like a better regex engine, macro string passing that doesn't mess up the escapes, and lexical scoping. I don't need fancy dynamic scripting stuff to scale up CMake quite a bit more. Currently my code is 3 macros deep. I'm not just talking about SCons and so forth. python scons, ruby's rake and jam are (currently) cmake's closest contenders. Don't forget Ant. As far as I'm concerned, a CMake contender is any build system that is very popular and can supplant the jobs that CMake does. we'll write our own custom build system in our favorite scripting language. It happens in the game industry all the time. Does it? I work in a related industry and I never heard of such. Only very large companies can afford that kind of luxury. Game developers are an extremely immature lot. They will write new build systems and new scripting languages because they can. Meaning, because they've fooled someone into paying them to do it. The game developer postmortems are filled with stories of we made this scripting language, it did things X Y Z for us, but it took forever and we really suffered from tools immaturity. Yet the industry keeps doing it over and over again. You could say that basically it's an industry of technical ferment. I hang out on the sweng-gamedev mailing list, and I'm forever hearing about guys who think a cross-platform build system is hacking Visual Studio .sln files to export values to other platforms. They'll drive everything from Visual Studio or some such. Scripting language gurus are a real threat to software stability. They're getting paid, and like a standing army they're gonna find a way to get used. That being said, the gaming industry is also mostly oriented towards one or two platforms, so the need for a comprehensive multiplatform system like cmake is also probably overkill. The mainstream game industry is oriented towards Windows, Sony Playstation3, Nintendo Wii, and XBox360. They need comprehensive cross-platform build systems and it appears that none exist yet. So it is with an eye towards stalking them that I ask these questions. I'd like to get paid to do things related to game industry concerns, seeing as how I'm an indie game developer. Rather than the orthogonal open source pays my bills stuff I'm currently doing. Mainstream game titles often have multi-million $ budgets and teams of 100 people working on them. Granted, the bulk of those are artists. Asset management systems are a big deal in the game industry. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Existing CMake plugin :
EXECUTE_PROCESS(COMMAND tclsh $ENV{HOME}/myTclScript.tcl OUTPUT_VARIABLE
ov RESULT_VARIABLE rv)
You are responsible for making sure tclsh is callable for your project's
users...
Similarly for python, ruby, perl, shell script, or *whatever*
Or, if you want it done as part of the build, same command line but with
ADD_CUSTOM_COMMAND...
Because there is such diversity out there and people have so many varied
opinions of which language would be ideal to use, CMake *already provides*
the ability to shell out to any script processor you would like.
CMake's -P scripting ability is actually quite powerful for what it is right
now, though with its own quirks, and incremental improvements are bound to
come over time, but...
...in the mean time, just use whatever scripting languauge you want. Make
macros that demonstrate how to run scripts at configure time and at build
time with your favorite script processor and submit them to the Wiki for
others to benefit from if you feel so inclined.
2 cents,
David
On 11/2/07, Eric Noulard [EMAIL PROTECTED] wrote:
Hi all,
I'm interested in the idea of a more powerful CMake scripting.
I'm convinced I lack powerful scripting sometimes (may be many times)
but my opinion is it's not CMake's script job.
2007/11/2, Sanchez, Juan [EMAIL PROTECTED]:
Tcl is a simple language, and is well understood. It has already been
ported to about every platform out there. You don't need QT or
wxWidgets,
because the Tk extensions of it already work.
I did some Tcl, Perl and Python.
Tcl syntax is really awkward at first sight.
You get used to it but not as fast Python.
I did some 7 years of Fortran programming (mostly F77 and F90)
then 10+ years of C++.
Fortran is far better than C++ for many things.
The converse is true too :=)
I used Java for 4+ years (all thoses years are overlapping :=)
it was really pleased using it for cross platform GUI.
And I was really disappointed because the java I used
was lacking generics such that I need to cast here and there when
using container.
I hope I've already put you on the road of
there is no FAR better language than other.
Personally if I were to extend or re-implement CMake
scripts I'll do it in Python because I _currently_
find it far more powerful than Tcl and pretty widespread too.
(I had even looked at SCons for this reason before using CMake).
But the fact is I don't think I _NEED_ a python
implementation of CMake but may be I would like
a Python plugin (or Tcl or Ruby or ...) for CMake.
This way we can keep the CMake scripting language
small and bug free (someday) and take the Python plugin
escape door when needed.
Many features in the CMake language don't really work the way people
expect, or are not documented, or both.
Documentation is not as good as it should be
but re-implementing something (either TCL, Python, Perl)
won't make the documentation better.
I know you'll inherit a clean syntax definition
(iff you ever chose python :=) but you won't get
the up to date documentation for your freshly
implemented functions.
As for bug I'm sure you know that fresh new software
usually have many more bugs than old one.
If anyone would like to fork cmake with me, I'm game.
Features:
Tcl frontend featuring modern dynamic language constructs and
consistent
syntax.
C pre-processor based dependency scanner
Accurate and up to date documentation
Focus on getting build system that works, because all of the language
constructs have already been written.
Developers who are not hostile to ideas concerning improvements to the
language.
I am convinced of the usefullness of improvement of the language
but I'm not convinced that a fork is the way to go.
What would you think of
CMAKE_LOAD_PLUGIN(TCL)
CMAKE_TCL(IN_VAR a
IN_VAR b
OUT_VAR g
OUT_VAR h
SCRIPT_STRING any tcl code)
or
CMAKE_TCL(IN_VAR a
IN_VAR b
OUT_VAR g
OUT_VAR h
SCRIPT_FILE /path/to/tcl_script.tcl)
In both cases you can run Tcl code from within CMake scripts
you give IN_VAR and you get OUT_VAR.
All this is my own opinion though :=)
--
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
2007/11/2, David Cole [EMAIL PROTECTED]:
Existing CMake plugin :
EXECUTE_PROCESS(COMMAND tclsh $ENV{HOME}/myTclScript.tcl OUTPUT_VARIABLE
ov RESULT_VARIABLE rv)
Yes you are right I can do that.
You are responsible for making sure tclsh is callable for your project's
users...
That why I would tell explicitly I want to use TCL/python...
CMAKE_LOAD_PLUGIN(TCL)
But again I may do it with some CMake MACRO.
Because there is such diversity out there and people have so many varied
opinions of which language would be ideal to use, CMake *already provides*
the ability to shell out to any script processor you would like.
I agree on this, no single language may suits everyone's need or taste.
CMake's -P scripting ability is actually quite powerful for what it is right
now, though with its own quirks, and incremental improvements are bound to
come over time, but...
Regarding CMake scripting you end-up with the choice
of adding Feature to CMake or decide it's better to escape to
perl,python, tcl ...
...in the mean time, just use whatever scripting languauge you want. Make
macros that demonstrate how to run scripts at configure time and at build
time with your favorite script processor and submit them to the Wiki for
others to benefit from if you feel so inclined.
OK I will do that.
--
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Nov 2, 2007 11:49 AM, Juan E. Sanchez [EMAIL PROTECTED] wrote: On Fri, 2 Nov 2007, Brandon Van Every wrote: To make real improvements in all of those areas, you'd need a lot of funding. What kind of mandate do you have? There's not much point in saying everything's gonna be better if you don't have the labor. This would be a community effort. I don't have the resources to strike out on my own. Without a bunch of gold bars at your disposal, I'd say the CMake community isn't going anywhere. Best to work on compromises within the community rather than sweeping changes. I like using cmake. The language is kind of a bitter pill for people in my organization to swallow. The most important item on my proposed feature list is the Tcl frontend. I know everyone champions their favorite scripting language, but my opinion is, if you go that route you're doomed. Pick something that programmers consider modern and sexy, or you're never going to get the mindshare. A key consideration that dominates my own thinking as of late: Who's gonna pay me to know language X ? I went back to C++ for this reason. I'm sorry but whatever its merits, Tcl is not a resume skill nowadays. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Brandon Van Every wrote: On Nov 2, 2007 11:49 AM, Juan E. Sanchez [EMAIL PROTECTED] wrote: On Fri, 2 Nov 2007, Brandon Van Every wrote: To make real improvements in all of those areas, you'd need a lot of funding. What kind of mandate do you have? There's not much point in saying everything's gonna be better if you don't have the labor. This would be a community effort. I don't have the resources to strike out on my own. Without a bunch of gold bars at your disposal, I'd say the CMake community isn't going anywhere. Best to work on compromises within the community rather than sweeping changes. I like using cmake. The language is kind of a bitter pill for people in my organization to swallow. The most important item on my proposed feature list is the Tcl frontend. I know everyone champions their favorite scripting language, but my opinion is, if you go that route you're doomed. Pick something that programmers consider modern and sexy, or you're never going to get the mindshare. A key consideration that dominates my own thinking as of late: Who's gonna pay me to know language X ? I went back to C++ for this reason. I'm sorry but whatever its merits, Tcl is not a resume skill nowadays. Actually Tcl is still quite popular. Many commercial electronic design automation (EDA) companies use Tcl frontends, and EDA is a billion dollar industry. Active State still seems to be doing well peddling their supported versions of Tcl as well. Apart from its consistent syntax, another big selling point is its truly free license. I'd be willing to entertain any other suggestions for scripting languages, as long as: 1. the syntax is consistent 2. the language is not bloated 3. the language does not require to much dressing up with parenthesis and commas 4. the license is BSD-like in nature. Note that OOP is more of a detriment than a benefit in my concept of simple scripting languages. Obfuscation by encapsulation is not a benefit in a flat file architecture. Regards, Jun ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Brandon Van Every wrote: Is it worth trying to address these problems and make CMake a better scripting language? Yes, but currently as a low priority. CMake first needs to have an extremely solid cross-compile toolchain and support as many systems as possible first without any major issues. CMake is already very close to getting there. I think in a year or so this will be achieved without major issues. Already the cmake2.5 internals and fixes are way better than the 2.4 branch. At that point it may indeed be worth forking cmake to improve or change its language. My concern is that if the status quo is maintained, CMake script will always be ugly to program with. Yes. No doubt about that. It is already uglier to program with than most modern scripting languages. Personally I think you need to see cmake as what it is: a tool to create makefiles. Not a scripting language. If you are doing lots of file, regex or string manipulation... alarms should be going off. You should probably write that as a small tool in ruby, perl or python and have cmake just call the command. This will put it at a disadvantage compared to build systems written in Python, Ruby, or Perl. Perl and TCL -- no. Perl because of the sygils and bad OO. TCL due to bad OO, brackets and weak regex. Ruby? Certainly. Its metalanguage allows for the creation of a next generation make system. But nobody is, afaik, actually working on one. Most rubyists are happy with rake, which is only a very simple make system and does not take full advantage of ruby meta language strengths. Python? Probably, but use of parenthesis still remains more cumbersome than what it should be (not as bad as cmake, thou). I do agree that sooner or later, the cmake macro language will become a disadvantage ( how soon? who knows--- I give it 3 to 5 years or even more ). The syntax of the language also will only matter when something matches cmake's features first. In the short run, I'm unaware of anything that will be successful at this. Currently all competing open source build systems are inferior feature wise to cmake. And cmake has had a lot more tuning in terms of properly setting compiler flags than any other build system I've used. Build systems built on top of scripting languages also suffer from being a tad bloated. Unless you plan to use the scripting language later for something else, you end up installing tons of libs the build system probably never uses (networking, web, ssh, ftp, etc). Another issue with other popular systems built on scripting languages is that they usually try to replace not just a tool like 'cmake' or 'autotools' but they replace 'make' also. Which is a neat idea, but also a potential mistake. This often makes troubleshooting build problems harder, as the build systems internals are often not as well documented as the api. One of the big strengths of cmake is that both the modules and the C++ is very readable. When you replace make, developers only familiar with IDEs are completely left out, unlike a tool like cmake. Another issue with scons, rake, etc. are that they are still slower than cmake's approach. For small projects, that may not matter, but today on large projects you still can notice. Even a difference of 10 seconds adds up to a lot when you consider the hundreds of iterations a C/C++ project has to go through to reach a stable state. The last headache with a build system built on top of a scripting language is that as soon as a better language appears, the build system may need to be rewritten or thrown out. CMake may indeed eventually need to replace its macro language, but all the C++ core and platform specific stuff can always remain regardless of the user front-end. And thankfully, cmake's internals are really very clean C++ code, so I am confident that even if Kitware were to refuse changing their language once lots of people start feeling the need for doing so, someone else can step up to the challenge. I'm not just talking about SCons and so forth. python scons, ruby's rake and jam are (currently) cmake's closest contenders. But they are not good or comprehensive enough to distinguish themselves (yet, at least). Python gives you a better language overall, but its syntax also gets in the way when writing rules. Rake is usually better, but it is a very barebones make system (think cmake sans modules). we'll write our own custom build system in our favorite scripting language. It happens in the game industry all the time. Does it? I work in a related industry and I never heard of such. Only very large companies can afford that kind of luxury. There usually is not enough time to create your build system. And the last thing you want is to then have to keep maintaining that build system, which is something 5 to 30 developers will use and must always work. That being said, the gaming industry is also mostly
Re: [CMake] improve the CMake language?
Hi all, I'm interested in the idea of a more powerful CMake scripting. I'm convinced I lack powerful scripting sometimes (may be many times) but my opinion is it's not CMake's script job. 2007/11/2, Sanchez, Juan [EMAIL PROTECTED]: Tcl is a simple language, and is well understood. It has already been ported to about every platform out there. You don't need QT or wxWidgets, because the Tk extensions of it already work. I did some Tcl, Perl and Python. Tcl syntax is really awkward at first sight. You get used to it but not as fast Python. I did some 7 years of Fortran programming (mostly F77 and F90) then 10+ years of C++. Fortran is far better than C++ for many things. The converse is true too :=) I used Java for 4+ years (all thoses years are overlapping :=) it was really pleased using it for cross platform GUI. And I was really disappointed because the java I used was lacking generics such that I need to cast here and there when using container. I hope I've already put you on the road of there is no FAR better language than other. Personally if I were to extend or re-implement CMake scripts I'll do it in Python because I _currently_ find it far more powerful than Tcl and pretty widespread too. (I had even looked at SCons for this reason before using CMake). But the fact is I don't think I _NEED_ a python implementation of CMake but may be I would like a Python plugin (or Tcl or Ruby or ...) for CMake. This way we can keep the CMake scripting language small and bug free (someday) and take the Python plugin escape door when needed. Many features in the CMake language don't really work the way people expect, or are not documented, or both. Documentation is not as good as it should be but re-implementing something (either TCL, Python, Perl) won't make the documentation better. I know you'll inherit a clean syntax definition (iff you ever chose python :=) but you won't get the up to date documentation for your freshly implemented functions. As for bug I'm sure you know that fresh new software usually have many more bugs than old one. If anyone would like to fork cmake with me, I'm game. Features: Tcl frontend featuring modern dynamic language constructs and consistent syntax. C pre-processor based dependency scanner Accurate and up to date documentation Focus on getting build system that works, because all of the language constructs have already been written. Developers who are not hostile to ideas concerning improvements to the language. I am convinced of the usefullness of improvement of the language but I'm not convinced that a fork is the way to go. What would you think of CMAKE_LOAD_PLUGIN(TCL) CMAKE_TCL(IN_VAR a IN_VAR b OUT_VAR g OUT_VAR h SCRIPT_STRING any tcl code) or CMAKE_TCL(IN_VAR a IN_VAR b OUT_VAR g OUT_VAR h SCRIPT_FILE /path/to/tcl_script.tcl) In both cases you can run Tcl code from within CMake scripts you give IN_VAR and you get OUT_VAR. All this is my own opinion though :=) -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Nov 2, 2007 1:01 PM, Juan Sanchez [EMAIL PROTECTED] wrote: Brandon Van Every wrote: On Nov 2, 2007 11:49 AM, Juan E. Sanchez [EMAIL PROTECTED] wrote: On Fri, 2 Nov 2007, Brandon Van Every wrote: To make real improvements in all of those areas, you'd need a lot of funding. What kind of mandate do you have? There's not much point in saying everything's gonna be better if you don't have the labor. This would be a community effort. I don't have the resources to strike out on my own. Without a bunch of gold bars at your disposal, I'd say the CMake community isn't going anywhere. Best to work on compromises within the community rather than sweeping changes. I like using cmake. The language is kind of a bitter pill for people in my organization to swallow. The most important item on my proposed feature list is the Tcl frontend. I know everyone champions their favorite scripting language, but my opinion is, if you go that route you're doomed. Pick something that programmers consider modern and sexy, or you're never going to get the mindshare. A key consideration that dominates my own thinking as of late: Who's gonna pay me to know language X ? I went back to C++ for this reason. I'm sorry but whatever its merits, Tcl is not a resume skill nowadays. Actually Tcl is still quite popular. Many commercial electronic design automation (EDA) companies use Tcl frontends, and EDA is a billion dollar industry. Active State still seems to be doing well peddling their supported versions of Tcl as well. Apart from its consistent syntax, another big selling point is its truly free license. I'd be willing to entertain any other suggestions for scripting languages, as long as: 1. the syntax is consistent 2. the language is not bloated 3. the language does not require to much dressing up with parenthesis and commas 4. the license is BSD-like in nature. I didn't realize that Ruby is GPLed. http://www.ruby-lang.org/en/LICENSE.txt Oh well, so much for embedding Ruby! Python is essentially BSD + requires that you make brief note of any changes to Python in derivative works. http://www.python.org/download/releases/2.5.1/license/ I don't know how embedded-friendly Python is, particularly in the presence of other Python installations. Python regexes are not inherently part of the syntax; of course, this is true of CMake script as well. Python certainly wins popularity contests, and a Python CMake done well would put SCons out of business + maybe steal their developers. Lua is MIT licensed. http://www.lua.org/license.html Lua is extremely embedded-friendly, that's its sole reason for existing. Lua has brand identity in the world of modern geekdom but is not, generally speaking, anywhere near as popular as Python or Ruby. It is quite popular in the game industry, however, because of a perception that it's lean and mean. I have no idea how beneficial or detrimental the language syntax is, I've never used it. Lua's pattern matching has character classes but not the | branching operator. http://www.lua.org/manual/5.1/manual.html#5.4.1 That's pretty much it for the list of suspects. I wouldn't hitch the CMake truck to Perl. Note that OOP is more of a detriment than a benefit in my concept of simple scripting languages. Obfuscation by encapsulation is not a benefit in a flat file architecture. You can write your non-OOP code however you want, and leave others to do what they want. It doesn't matter as far as off-the-shelf languages go. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Brandon Van Every wrote: My concern is that if the status quo is maintained, CMake script will always be ugly to program with. This will put it at a disadvantage compared to build systems written in Python, Ruby, or Perl. I'm not just talking about SCons and so forth. I'm talking about a shop deciding, hey, screw this off-the-shelf stuff, we'll write our own custom build system in our favorite scripting language. It happens in the game industry all the time. Your thoughts? CMake is a build system. In an ideal world, the language would be purely declarative. Basically, you would describe things you want to build, and CMake would build them. In practice, this is too restrictive, and a small amount of programming makes things easier. I never wanted CMake to replace perl, ruby, python or any other language. I wanted CMake to not depend on another language being installed. CMake only depends on a C++ compiler being around, so CMake can be built. Since CMake was developed for ITK (a c++ toolkit), I was adding no additional restrictions to the build process. The scripting stuff actually came out of a desire to automate the testing system without the use of tcl as was required in earlier version of Dart. I am sure the CMake language will be tweaked here and there, but if you have a big programming job that has nothing to do with building software, then CMake is the wrong choice. So, I think that if something is hard to build because of the CMake language, then we should fix it. People should use CMake because it is really easy to build complex things with, and not because it has a great language. The hard stuff should be done in C++ commands. For example, this small line of CMake code: add_library(foo SHARED foo.cxx) does some very complicated stuff as it builds shared libraries on many platforms, and different IDE's. And most of that is not done with the CMake language, it is done with the more powerful C++ language. BTW, I hope this does not become a long discussion, but I am sure it will... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] improve the CMake language?
Tcl is a nice language for implementing declarative commands. It can be easily
built on about every platform out there, and the language rules are well known.
It is small, and very easy to compile a standalone Tcl based interpreter with
the CMake commands built in. The user would not need to have any language
installed, you could package the source with CMake or make it part of the cmake
binary you distribute. It is freely distributable and has a BSD license.
add_library(foo SHARED foo.cxx)
could become
add_library {foo SHARED foo.cxx}
or even
add_library -name foo -type SHARED foo.cxx
Please see:
http://en.wikipedia.org/wiki/Tcl
for a description of this language. It would be very easy to implement a macro
as a procedure.
I would be happy to participate in any effort to port the cmake commands to a
Tcl interpreter. Please let me know if you are interested.
Regards,
Juan
-Original Message-
From: [EMAIL PROTECTED] on behalf of Bill Hoffman
Sent: Thu 11/1/2007 8:03 PM
To: Brandon Van Every
Cc: cmake@cmake.org
Subject: Re: [CMake] improve the CMake language?
Brandon Van Every wrote:
My concern is that if the status quo is maintained, CMake script will
always be ugly to program with. This will put it at a disadvantage
compared to build systems written in Python, Ruby, or Perl. I'm not
just talking about SCons and so forth. I'm talking about a shop
deciding, hey, screw this off-the-shelf stuff, we'll write our own
custom build system in our favorite scripting language. It happens in
the game industry all the time.
Your thoughts?
CMake is a build system. In an ideal world, the language would be
purely declarative. Basically, you would describe things you want to
build, and CMake would build them. In practice, this is too
restrictive, and a small amount of programming makes things easier. I
never wanted CMake to replace perl, ruby, python or any other language.
I wanted CMake to not depend on another language being installed. CMake
only depends on a C++ compiler being around, so CMake can be built.
Since CMake was developed for ITK (a c++ toolkit), I was adding no
additional restrictions to the build process. The scripting stuff
actually came out of a desire to automate the testing system without the
use of tcl as was required in earlier version of Dart. I am sure the
CMake language will be tweaked here and there, but if you have a big
programming job that has nothing to do with building software, then
CMake is the wrong choice.
So, I think that if something is hard to build because of the CMake
language, then we should fix it. People should use CMake because it is
really easy to build complex things with, and not because it has a great
language. The hard stuff should be done in C++ commands.
For example, this small line of CMake code:
add_library(foo SHARED foo.cxx)
does some very complicated stuff as it builds shared libraries on many
platforms, and different IDE's. And most of that is not done with the
CMake language, it is done with the more powerful C++ language. BTW, I
hope this does not become a long discussion, but I am sure it will...
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Sanchez, Juan wrote: Tcl is a nice language for implementing declarative commands. It can be easily built on about every platform out there, and the language rules are well known. It is small, and very easy to compile a standalone Tcl based interpreter with the CMake commands built in. The user would not need to have any language installed, you could package the source with CMake or make it part of the cmake binary you distribute. It is freely distributable and has a BSD license. We are not doing CMake in Tcl! We specifically avoided it at the start. From what I can tell it is declining, and the compile a standalone thing was never that easy, and we (Kitware) have plenty of experience with tcl. Please don't bother to refute this ... ( I am ranting a bit). CMake would require Tcl to build, right now it only needs C++, and I aim to keep it that way. I will say this. Unless someone is going to fork CMake, I do not think there will be a new language. I guess I should just stay on the side lines until the current change the language thread is over... SIGH... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Sanchez, Juan wrote:
Tcl is a nice language for implementing declarative commands. It can be
easily built on about every platform out there, and the language rules
are well known. It is small, and very easy to compile a standalone Tcl
based interpreter with the CMake commands built in. The user would not
need to have any language installed, you could package the source with
CMake or make it part of the cmake binary you distribute. It is freely
distributable and has a BSD license.
add_library(foo SHARED foo.cxx)
could become
add_library {foo SHARED foo.cxx}
or even
add_library -name foo -type SHARED foo.cxx
I can't help myself, I have to respond :)
Or it could be:
add_library(foo SHARED foo.cxx)
Hey, wait, that already works... :)
The point is you don't need tcl, python, or ruby to add add a library.
You need a simple language, and I want it to work with only a c++
compiler and its standard libraries. So, when someone wants to build a
c++ program with CMake on a new platform, they don't first have to port
(tcl/python/ruby/XXX), the just need to have a c++ compiler, which they
should have if they are building a c++ application. It is sort of a
prerequisite to have a c++ compiler to build a c++ application, so we
know it will be there.
Sorry Juan, your suggestion is valid, and perhaps I should create a FAQ
entry like: Why the CMake Language? So, I can point to it when this
comes up.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] improve the CMake language?
Hello Bill,
add_library(foo SHARED foo.cxx)
won't work.
Parenthesis are not part of the standard syntax, and worth getting Tcl to
understand them.
Tcl is a simple language, and is well understood. It has already been ported
to about every platform out there. You don't need QT or wxWidgets, because the
Tk extensions of it already work.
Many features in the CMake language don't really work the way people expect, or
are not documented, or both.
If anyone would like to fork cmake with me, I'm game.
Features:
Tcl frontend featuring modern dynamic language constructs and consistent syntax.
C pre-processor based dependency scanner
Accurate and up to date documentation
Focus on getting build system that works, because all of the language
constructs have already been written.
Developers who are not hostile to ideas concerning improvements to the language.
Regards,
Juan
-Original Message-
From: Bill Hoffman [mailto:[EMAIL PROTECTED]
Sent: Thu 11/1/2007 9:18 PM
To: Sanchez, Juan
Cc: Bill Hoffman; Brandon Van Every; cmake@cmake.org
Subject: Re: [CMake] improve the CMake language?
Sanchez, Juan wrote:
Tcl is a nice language for implementing declarative commands. It can be
easily built on about every platform out there, and the language rules
are well known. It is small, and very easy to compile a standalone Tcl
based interpreter with the CMake commands built in. The user would not
need to have any language installed, you could package the source with
CMake or make it part of the cmake binary you distribute. It is freely
distributable and has a BSD license.
add_library(foo SHARED foo.cxx)
could become
add_library {foo SHARED foo.cxx}
or even
add_library -name foo -type SHARED foo.cxx
I can't help myself, I have to respond :)
Or it could be:
add_library(foo SHARED foo.cxx)
Hey, wait, that already works... :)
The point is you don't need tcl, python, or ruby to add add a library.
You need a simple language, and I want it to work with only a c++
compiler and its standard libraries. So, when someone wants to build a
c++ program with CMake on a new platform, they don't first have to port
(tcl/python/ruby/XXX), the just need to have a c++ compiler, which they
should have if they are building a c++ application. It is sort of a
prerequisite to have a c++ compiler to build a c++ application, so we
know it will be there.
Sorry Juan, your suggestion is valid, and perhaps I should create a FAQ
entry like: Why the CMake Language? So, I can point to it when this
comes up.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
