Re: [CMake] CMake with Lua Experiment
- The source code seems to have been crappified by windows. There's missing +x permissions on executable files and cr-lf linefeeds everywhere. - The source does: #include lua.h but the bootstrap/cmakelists.xt does not search for paths to it. Under my Ubuntu box, lua.h is located in lua5.1/lua.h or lua5.0/lua.h, not under the main /usr/include. So I'm wondering if there is a cleaned up version of the code yet. I'm having a hard time dealing with both the cr-lf and the Lua detection on my Mac. - The approach of a single cmCommand.cxx to parse functions is probably limiting as it makes it harder to make the command syntax more flexible. I wanted to comment on this. I think this is a workable situation. I was thinking, instead of trying to change things at the C++ level, it would be a lot easier to handle this at the Lua level. We can create a CMake/LuaUtility module which always gets included and create a public API there. Each public API function in here basically just calls the CMake/Lua function that was binded in cmCommand.cxx. But in the utility module, we do all the argument parsing and validation we see fit. I've submitted an example and updated the page: http://www.cmake.org/Wiki/CMake:Experiments_With_Lua The example shows different ways scripters may want to pass files to add_library and a simple function that handles it. Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Jesper Eskilson wrote: Many systems (even the *really* large ones) are actually very simple to their layout; projects are often isomorphic so that each CMakeLists.txt is more or less just a list of files to compile. But other systems (both large and small) are simply to complicated to maintain a build system for without a proper language at your disposal. GCC and the Linux kernel are good examples of the latter (neither of which actually do have a good build system language, but that's another story). A little off topic, but GCC via gcc_xml http://www.gccxml.org/HTML/Index.html is built by CMake, and did not require a language. Most of the complication comes at build time with custom commands that generate files that generate files, that generate files. The build script it self does not have to do much programming. Most of the hard work is pushed to build time, and not CMake time. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 29, 2007 2:18 AM, Jesper Eskilson [EMAIL PROTECTED] wrote: Brandon Van Every wrote: On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. No offense, but you're not really in a position to determine what constructs are benefitial for people in their own build systems. I'm saying any reasonable implementation of scope would satisfy me at present. We all have our points of view about how important various things are. Alexander has gone on record as anti-complexity; he Considers Programming Harmful in a build system. I don't agree with him; I figure if I need scope today, perhaps I'll need OO or FP 5 years from now. People in the computer industry have a history saying newfangled stuff isn't needed, and people are always proven to be partly wrong. I don't have reactionary views about using fullblown programming languages in build systems. I don't feel threatened by them. I do think that people can run away with their abstractions and turn their build system into a PITA. But I also think that large scale open source projects that *I* have to deal with, have some cultural safeguards against that. I'm not worried about being tortured by someone else's horrible build system... and if it's really that bad, I have a consulting opportunity to write something better. I'm very conscious of the marketing value of fullblown programming languages. People think they need them, whether they need them or not. I may only want some very basic scope out of Lua, but I'd be quite happy if the world flocked to CMake for other Lua bells and whistles. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 29, 2007 12:37 PM, Brandon Van Every [EMAIL PROTECTED] wrote: We all have our points of view about how important various things are. Alexander has gone on record as anti-complexity; he Considers Programming Harmful in a build system. I don't agree with him; I figure if I need scope today, perhaps I'll need OO or FP 5 years from now. It occurs to me, furthermore, that CMake is a self-selecting community for discussing the issue. CMake doesn't have fancy programming capabilities. So, if that's a dealbreaker for someone, they probably won't stick around. The people who do stick around, are likely to tell newcomers that a lack of programming capabilities is just fine. This culture is enforced by the technology. CMake is a fairly successful build system, and so is Autoconf, so maybe there's something to be said for this culture. But it is a culture, and it's probably better to solicit perspectives outside the culture. Consequently, I'm starting to ask around on more general purpose build engineering lists, about what value they see in OO or other programming constructs. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: As DSL based on Lua != Lua, assuming Kitware gets rid of documentation and bugs in the language might be too optimistic. Look for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based DSL for hardware description, like Verilog or VHDL, but it's so different from Ruby you need to produce the whole documentation again. So? So far I'm the only person who has proposed changing Lua syntax. I've only listed 2 items: excessive quotes and unpack(table). Nothing would stop anyone from using quotes all over the place or unpack(table), i.e. standard Lua would still work. It may even be possible for these minor tweaks to be transparently corrected as far as 3rd party Lua libraries are concerned. If it's 95% Lua it's still Lua. We're talking about a 1 page addendum to the docs, tops. Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get for free, whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. We already had the extended discussion about possible CMake scope implementations, so I'm not understanding what you're asking. I assumed that Kitware is ready to act when they have time to do so. Did you miss that discussion? Did it leave you with a bunch of unresolved questions? If so, I'd suggest going back into the archive and responding to specific things you're unclear about. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
(Aside: what's with the cm_ prefix?)
The cm_ prefix was something Ken put in his demo. I assumed he was
trying to 'namespace' the thing. I personally like the idea and really
think it should have been applied to the regular CMake language. Often
when I have to read other people's code, I can't distinguish between
the 'official' API functions are and the userland functions when I do
not know the official API very well. I certainly had this problem with
CMake when I first started out, and I also have this problem with
CMake functions that I forget about or don't know about either due to
legacy redundancy/obsoletion or new things introduced.
As I said, the use of unpack() was
unnecessary.
I'm doubting that's correct. I doubt that sources and unpack(sources)
are the same thing at all.
So you're not listening. What I said is:
cm_add_library( simpleLib, STATIC, simpleLib.cxx,
simpleCLib.c, simpleWe.cpp)
is identical to:
sources = {simpleLib.cxx, simpleCLib.c, simpleWe.cpp}
cm_add_library( simpleLib, STATIC, unpack(sources))
In both cases, the function cm_add_library receive 5 strings as arguments.
I'm also saying that is it easy to implement cm_add_library so you can
handle the above case (the vararg case) but you can also handle the
case where the user does:
cm_add_library( simpleLib, STATIC, sources)
In this case, cm_add_library receives 2 string arguments and 1 table
argument. The implementation of cm_add_library can be easily written
to handle both cases so the CMake scripter can write whatever seems
most natural to them. This makes the need for unpack() unnecessary.
Yes I know. I was saying that passing file1.c file2.c file3.c is
not a solution to Lua's excessive quoting problem, because you'd be
sacrificing desireable processing capabilities. We want to be able to
operate on lists/tables of stuff with FOREACH, LIST, individuated
parameters, and so forth.
I'm not understanding what you're getting at. But I think this is
probably much ado about nothing. Once you get your files into a table,
you can do all your expected foreach/list stuff. There won't be any
excessive quoting here. I don't see any reason while the CMake FOREACH
couldn't also be exposed through a Lua API either so you should be
able to use which ever fits best.
The point is that the marketing luster of Lua will fade. The legacy
CMake builds will all be using an old, hoary version of Lua. CMake
will have to support those old builds to some degree. It won't be
able to utilize newfangled Lua stuff, if the newfangled stuff breaks
backwards compatibility. I bet there are problems between Python
1.5.2 and 2.5.1, although I'm not up on them. I bet the Python
community doesn't consider Python 1.5.2 a sales point, if they stare
closely at SCons. Now, people may not stare closely. And in any
event, the luster of Lua will probably last 5 years. But then it'll
be over, and the real question will be, was it a cool choice for text
processing? 'Cuz that's what a build system mostly is.
What we really want is Ruby without the licensing hassles. And a bit
faster.
Well, not really. Embedding Ruby (or Python) is a lot harder than
embedding Lua. There are very few languages that focus specifically on
this niche. Most languages want to be the end-all and offer great
libraries to easily build certain types of things (Rails, Twisted).
Lua's focus is embedding which is why it is a great tool for this
specific kind of job with regards to CMake.
As far as Ruby syntax is concerned, I don't see how it is
significantly different than Lua. All the Ruby code I've seen also has
quotes around string literals and commas separating items in lists.
But I wouldn't worry much about the speed of Ruby. Most of the
performance bottlenecks will be within CMake itself doing the heavy
lifting and file I/O. It's just nice that with Lua, you don't have to
fend off detractors on the speed argument so much. But I don't see it
as a real problem.
As for marketing, I can't predict the future. Any language is subject
to these whims. We could all be writing in Lisp some day. However, Lua
has been around for awhile (it's older than Java) and I don't expect
it to disappear. And adoption of Lua has been driven more by the fact
that it's a really good tool for solving specific sets of problems,
not so much marketing. (It's just interesting that World of Warcraft
has suddenly changed the marketing aspect because the game is so
huge.) I can say with some certainty that even if the marketing loses
its luster, it will still be an easier sale than marketing CMake's
proprietary language.
cm_add_library( simpleLib, STATIC, sources)
That's an improvement.
I wish we could get rid of quotes in places that don't need them. How
easy would it be to modify Lua in that regard? So, CMake would be a
Lua variant rather than straight Lua.
cm_add_library( simpleLib, STATIC, sources)
So, as I said, there are some tokenizer/macro
Re: [CMake] CMake with Lua Experiment
Is backward compatibility with the current language a goal of the LUA experiment? I ask because the examples spoken of on this list appear to be trying to mimic the current CMake syntax. Right now I think it's just an experiment to see how things might work, how much effort would be involved, and how much of an impedance mismatch there will be with how things are currently done. It sounds like things may not progress any further unless a real long term vision for CMake is developed and embraced. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
I'd also like a shorter way to dereference a table than unpack(table). Seriously, this is a total non-issue and unpack is totally unnecessary. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Quoting Brandon Van Every [EMAIL PROTECTED]: Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get for free, whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. We already had the extended discussion about possible CMake scope implementations, so I'm not understanding what you're asking. I assumed that Kitware is ready to act when they have time to do so. Did you miss that discussion? Did it leave you with a bunch of unresolved questions? If so, I'd suggest going back into the archive and responding to specific things you're unclear about. Do you mean these threads? http://www.cmake.org/pipermail/cmake/2005-March/006235.html http://www.cmake.org/pipermail/cmake/2005-June/006725.html If that is so, yes, I guess I missed them (I was not using CMake back then :-). If you are talking about a different thread, could you please tell me which one? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:13 AM, E. Wing [EMAIL PROTECTED] wrote:
(Aside: what's with the cm_ prefix?)
Often
when I have to read other people's code, I can't distinguish between
the 'official' API functions are and the userland functions when I do
not know the official API very well.
Yeah but that's your fault. :-) Do enough CMake and you're gonna
know that add_library isn't something anyone made up. I will admit
that a few of the uncommon functions could throw me. Like site_name,
which I only learned the other day after 2 years of hardcore staring
at CMake all the time. But I looked it up no big deal, right?
Furthermore, the CMake 2.6 docs have a better breakdown, there's a
CMake Commands Only section with a HTML index. These are separate
from the standard modules, which now have their own section. Module
names are exceedingly verbose, you're not going to mistake them. So
it's trivial to learn the reserved commands, there's maybe ~60 of
them, all concisely indexed in one place. The depreciated commands
have been moved out, thinning the ranks.
As I said, the use of unpack() was
unnecessary.
I'm doubting that's correct. I doubt that sources and unpack(sources)
are the same thing at all.
So you're not listening. What I said is:
In both cases, the function cm_add_library receive 5 strings as arguments.
No, we're talking past each other. I said I figured it out after
reading the docs for 15 minutes. I was saying, in a long-winded
manner, that CMake script's ${list} is equivalent to Lua's
unpack(table), and that CMake is less verbose than Lua for list/table
dereferencing. Since this is an operation that I do all the friggin'
time in 1/2 the lines of code I write, I consider it important.
I'm also saying that is it easy to implement cm_add_library so you can
handle the above case (the vararg case) but you can also handle the
case where the user does:
cm_add_library( simpleLib, STATIC, sources)
And I think rewriting all the CMake functions to dereference
lists/tables on the user's behalf is busywork. Nor do I, as a
programmer, want my lists/tables automagically dereferenced. When
it's my turn to write standard modules, macros, or functions, I want
clear expectations about who's gonna do the work. What the expected
type of input is, and what an error is.
What we really want is Ruby without the licensing hassles. And a bit
faster.
Well, not really. Embedding Ruby (or Python) is a lot harder than
embedding Lua.
And a bit smaller.
As far as Ruby syntax is concerned, I don't see how it is
significantly different than Lua.
And a bit more PCRE. Lua's inherent regexes are weird.
All the Ruby code I've seen also has
quotes around string literals and commas separating items in lists.
Ok my bad. I keep thinking of Ruby as souped up Perl. Seems like
Perl, Make, CMake, and various shells are the sane ones as far as
string entry.
As for marketing, I can't predict the future. Any language is subject
to these whims. We could all be writing in Lisp some day.
Ain't gonna happen. The market has spoken: Lisp is weird. People
will use it, and its use may even increase, but it's never going to be
a majority language. Rather, the majority languages will steal Lisp
features and make them less weird.
One thing to be aware of though. Notice strings are quotes, but
variables are not (like C/C++). So an ambiguity problem may be
created. So if I were to do something like:
myLibraryName = simpleLib
listOfFilesFound = cm_file(GLOB, *.c) -- wrapper around CMake FILE,
but utilizes return parameter
cm_add_library(myLibraryName, STATIC, listOfFilesFound)
Notice that all the quotes are gone by the cm_add_library command
because everything was somehow placed into a variable.
But that's wrong. Should be
add_library(myLibraryName, STATIC, ${listOfFilesFound})
where of course we've implemented ${} instead of unpack() ;-)
For any given CMake function, we know what argument types we expect.
The programmer is responsible for dereferencing, we're not going to do
it for them. We just have to parse the keywords like STATIC, and pay
attention to fixed positions at the beginning of an argument list. In
fact, come to think of it, if it's a CMake reserved function, hand it
off to a special argument processor, would solve much of the problem.
Then you're just down to changing Lua table constructors, so that
they don't require quotes.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:59 AM, Brandon Van Every [EMAIL PROTECTED] wrote: For any given CMake function, we know what argument types we expect. The programmer is responsible for dereferencing, we're not going to do it for them. We just have to parse the keywords like STATIC, and pay attention to fixed positions at the beginning of an argument list. In fact, come to think of it, if it's a CMake reserved function, hand it off to a special argument processor, would solve much of the problem. Then you're just down to changing Lua table constructors, so that they don't require quotes. Unfortunately it has to work for user created functions also, so I guess it's not quite so simple. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:17 AM, E. Wing [EMAIL PROTECTED] wrote: Right now I think it's just an experiment to see how things might work, how much effort would be involved, and how much of an impedance mismatch there will be with how things are currently done. It sounds like things may not progress any further unless a real long term vision for CMake is developed and embraced. Gee you want one of those? :-) Here's one: happy, shiny programmers using a happy, shiny, fullblown programming language to implement entire build systems with little or no reference to external Perl, Python, or Ruby code. People wouldn't have much need for those if CMake's language features were sufficient. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:40 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: Do you mean these threads? http://www.cmake.org/pipermail/cmake/2005-March/006235.html http://www.cmake.org/pipermail/cmake/2005-June/006725.html These are not the threads you're looking for. If you are talking about a different thread, could you please tell me which one? lexical scoping http://public.kitware.com/pipermail/cmake/2007-November/017385.html Must say, I couldn't find this by using the Kitware mailing list search engine on the keywords lexical scoping. Most baffling since it's the subject line. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:20 AM, E. Wing [EMAIL PROTECTED] wrote: I'd also like a shorter way to dereference a table than unpack(table). Seriously, this is a total non-issue and unpack is totally unnecessary. The argument evaluation model matters. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Variable scoping (was Re: [CMake] CMake with Lua Experiment)
Quoting Brandon Van Every [EMAIL PROTECTED]: On Nov 28, 2007 3:40 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: Do you mean these threads? http://www.cmake.org/pipermail/cmake/2005-March/006235.html http://www.cmake.org/pipermail/cmake/2005-June/006725.html These are not the threads you're looking for. If you are talking about a different thread, could you please tell me which one? lexical scoping http://public.kitware.com/pipermail/cmake/2007-November/017385.html Must say, I couldn't find this by using the Kitware mailing list search engine on the keywords lexical scoping. Most baffling since it's the subject line. Wow. I did not read a single message in that thread. I would have suggested inlining the scope of the variable in the variable name, like Ruby does, instead of SET, SET(LOCAL ...), VARIABLE_SCOPE, etc: * variable = local variable * @variable = instance variable * @@variable = class variable * $variable = global variable * VARIABLE = constant Of course it would be different in CMake. Here comes a quick'n'dirty proposal: * variable = global variable (keep compatibility with CMake 2.4) * @variable = local variable (for example, inside a macro, if, foreach, etc) * @@variable = module (= file) variable (for instance, for Find.cmake modules). It does not exist outside the current file (even INCLUDE'ing a file which defines @@variable would NOT make @@variable available outside the file which defined it). * VARIABLE = constants defined by modules (Find.cmake), cannot be changed after setting it (this way it's impossible to accidentally modify for example QT_LIBRARIES in a CMakeLists.txt) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Ya know, if we took all the energy and time that has gone into debating this issue and instead focused it on CMake dev we might solve some problems a bit quicker. Mike ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 9:39 AM, Mike Jackson [EMAIL PROTECTED] wrote: Ya know, if we took all the energy and time that has gone into debating this issue and instead focused it on CMake dev we might solve some problems a bit quicker. Not really. In terms of my personal energy, it was absolutely trivial to entertain this discussion so far. And as far as I'm concerned, such discussions are important before just leaping off in some direction that's expensive to pursue. But if you're ready to just do something, by all means do it. There's a CMake lexical scoping paradigm just waiting to be implemented that we already had a long discussion about. I'm not talking about that because as far as I'm concerned, we already said what needed to be said. I do think Pau's idea about using a few special characters to distinguish variable name scope has merit, but I will let others debate the pros and cons of it. Frankly, I see it as a race between the supposed ease of improving the CMake language, and the demonstrated ease of slapping Lua into it. With provisios about whether we really want straight Lua; at present I don't, so I'm inclined towards more work. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Wednesday 28 November 2007, Brandon Van Every wrote: On Nov 28, 2007 3:17 AM, E. Wing [EMAIL PROTECTED] wrote: Right now I think it's just an experiment to see how things might work, how much effort would be involved, and how much of an impedance mismatch there will be with how things are currently done. It sounds like things may not progress any further unless a real long term vision for CMake is developed and embraced. Gee you want one of those? :-) Here's one: happy, shiny programmers using a happy, shiny, fullblown programming language to implement entire build systems I for one really don't want that. I don't want a full blown programming language in my build scripts. I don't want to understand actual programs when looking at build files. IMO it is ok that the cmake language is limited, this way you don't end up with programs as build files. This is what can happen if you use scons, then you have programs as build scripts. And everybody can program something more fancy. IMO this is wrong for a build system. Still having some type of variable scoping would be nice to have :-) Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 1:28 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: On Wednesday 28 November 2007, Brandon Van Every wrote: On Nov 28, 2007 3:17 AM, E. Wing [EMAIL PROTECTED] wrote: Right now I think it's just an experiment to see how things might work, how much effort would be involved, and how much of an impedance mismatch there will be with how things are currently done. It sounds like things may not progress any further unless a real long term vision for CMake is developed and embraced. Gee you want one of those? :-) Here's one: happy, shiny programmers using a happy, shiny, fullblown programming language to implement entire build systems I for one really don't want that. I don't want a full blown programming language in my build scripts. I don't want to understand actual programs when looking at build files. IMO it is ok that the cmake language is limited, this way you don't end up with programs as build files. This is what can happen if you use scons, then you have programs as build scripts. And everybody can program something more fancy. IMO this is wrong for a build system. Still having some type of variable scoping would be nice to have :-) I somewhat agree with you. I'm not a fan of here's this tweaky thing you can do in Lua or Ruby. The few times I've tried to be helpful when a group was trying to get their build system off the ground (was it OpenSceneGraph or G3D, I forget?) I railed against programmatic approaches. It's way easier for me to understand straight CMake script than a pile of gratuitous abstractions that some programmer thought would be kewl. *However*, the need for robust scoping has been proven in my own and other people's work. As far as I'm concerned it's not just a nice to have item. Strategically, over the next 10 years, it is an essential item to have. Or CMake will someday be regarded as an unacceptable toy, incapable of meeting the complexity requirements of the software of the day. CMake is currently ahead of the competition in terms of capabilities; over the long haul, that happy fact is not guaranteed. Just as we all hate Autoconf now, if CMake is not forwards-looking as far as capabilities, someday we will all hate CMake. [*] Because I see the need for scoping at present, I'm willing to concede the possibility that Object Orientation, or some other higher level organizational paradigm, may be needed in the future. I don't know at what point in the future, and I expect later rather than sooner, but nevertheless technology marches on. ASM code gave way to C code, C code gave way to C++ code, C++ code gave way to Java code. Each generation of programmers claimed a lack of need, and each generation is consistently proven to be partly wrong. The old technologies and paradigms persist, but new technologies and paradigms emerge and capture large chunks of programmer marketshare. I'm sensitive to the imperatives of marketshare. I want more money in CMake consulting. I want more money in Open Source cross-pollenation between Unix and Windows. So, if fancier programming constructs make a tool vastly more popular, I take that into consideration. [*] Frankly some people hate CMake now, and they don't make it a secret. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Brandon Van Every wrote: On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: As DSL based on Lua != Lua, assuming Kitware gets rid of documentation and bugs in the language might be too optimistic. Look for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based DSL for hardware description, like Verilog or VHDL, but it's so different from Ruby you need to produce the whole documentation again. So? So far I'm the only person who has proposed changing Lua syntax. I've only listed 2 items: excessive quotes and unpack(table). Nothing would stop anyone from using quotes all over the place or unpack(table), i.e. standard Lua would still work. It may even be possible for these minor tweaks to be transparently corrected as far as 3rd party Lua libraries are concerned. If it's 95% Lua it's still Lua. We're talking about a 1 page addendum to the docs, tops. Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. No offense, but you're not really in a position to determine what constructs are benefitial for people in their own build systems. Build systems look very different in different places, and assuming that you know whats best for everybody is a good way to make people want to move away from CMake. Many systems (even the *really* large ones) are actually very simple to their layout; projects are often isomorphic so that each CMakeLists.txt is more or less just a list of files to compile. But other systems (both large and small) are simply to complicated to maintain a build system for without a proper language at your disposal. GCC and the Linux kernel are good examples of the latter (neither of which actually do have a good build system language, but that's another story). But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get for free, whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. No, but having (or being) a real programming language is still one of the main benefits of using SCons (IMO). Still, I went with CMake for our build system, primarily due to the superior support for generating Studio project files, and the fact that SCons has *major* performance issues, especially on Windows. I would like to claim that the input to the build systems (Makefiles, SConsctruct, CMakeLists.txt, etc.) should be considered as source code, with all the implications that has: checked into version control, subject to code quality standards, subject to code review, etc. Given that standpoint, having a real programming language in your build system is very natural. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Hi Ken, Wow, thank you for playing with this. I personally think it's great. Every so often, I have to write some evil stuff in CMake script, and it always leaves me frustrated with things sometimes not working correctly. Working with a well known and well defined language is a big plus for me, and also makes it easier to convince others people to pick up CMake. Remember the argument 'I don't want to learn another language' also works against CMake because the majority of people are not CMake users already. Having a simple language that is known, proven, and documented is a real way to get past the barrier to entry. Of all the scripting languages, I've found Lua to be both one of the easiest to pick up by non-scripters, and also one of the easiest for C/C++ programmers to quickly understand without triggering a visceral response in them. The syntax is elegant yet powerful, and Lua syntax more closely resembles C/C++ than many other popular scripting languages which makes it friendly to C/C++ people. Since the majority of people using CMake are C and C++ people, I think it is important to consider the latter too because I was once burned by having to pick up Tcl quickly in a predominantly C environment and I struggled with it. Habits and conventions I took for granted in C like whitespace and braces were something I automatically ignored, while it turned out to be incredibly significant in a small piece of Tcl code I was trying to get to work. (And the Tcl compile/runtime error I got was useless.) For me, Lua has been very compatible with the C mental model, with only a few annoyances (like != in C is ~= in Lua). And from a marketing standpoint, it's easy to say, 'using the language of World of Warcraft, Far Cry, Baldur's Gate, Grim Fandango, Escape From Monkey Island, and many others' and get people excited. So some more specific notes: The Windows line feeds and whatnot are mucking up my build attempt. I don't think you need to use unpack. You should be able to just pass a table. It is possible to write the implementation detail to handle either case I believe. It's true that CMake's language currently gives some nice features like the ability to omit commas and quotes, and case-insensitivity. There is a new macro processor for Lua that is supposed to help with these kinds of things with the intent of helping projects create their own domain specific customizations. It works on top of Lua so you don't have to modify Lua itself. I've never used it myself and don't know it's capabilities and limitations. The risk of this though is that you now deviate from standard Lua documentation. However, if it can be used in limited scenarios, there might be some benefits. If quotes and commas are a real pain and you don't want to use the macro thing, you can also pass things in as block strings and parse them yourself, but I always worry about the reliability of these things. Relying on the compiler for syntax errors is usually a plus, but here's a snippet of what the syntax might look like: -- Use square bracket quote for block string sources = [[ simpleLib.cxx simpleCLib.c simpleWe.cpp ]] Then something has to be written to parse this string, presumably a split on whitespace type thing (but what about filenames with spaces? Bleh) One suggestion, I personally like using a nested table to give functions namespaces. So instead of cm_add_library, you could do cm.add_library. The standard Lua libraries do this (math., table., io.,). There are a whole bunch of documented tricks users can then apply to simulate 'using namespace' and so forth. On #include lua.h, because Lua can be placed anywhere (lua, lua50 lua51, lua5.1, etc), I recommend #include lua.h with a robust FindLua.cmake module. (FYI, I on OS X, I have a framework.) I remember somebody was working on one, and I was supposed to submit mine which I have been lagging on, but it basically tries to deal with a lot of this. One of the tricky parts though is how to deal with the Lua standard library. Pre-5.1, it was traditionally a separate library while post 5.1 it is often rolled together. But either way, people can (de)bundle them. But if you embed Lua, this problem goes away. (Also, every non-patch version of Lua reserves the right to break the API/ABI so this is a secondary problem not bundling Lua has to deal with.) Assuming Lua does become a permanent component, then embedding Lua is easy enough and shouldn't impact the CMake build process much. Lua is small and compiles fast (especially compared to the CMake core). The Lua core is 100% ANSI C and purposely keeps a lot of platform specific stuff out so it is really easy to build on any platform. Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake with Lua Experiment
- The source code seems to have been crappified by windows. There's missing +x permissions on executable files and cr-lf linefeeds everywhere. Yup, just a quick zip of what is on my disc which is windows hence the CR/LF etc. - The source does: #include lua.h but the bootstrap/cmakelists.xt does not search for paths to it. Under my Ubuntu box, lua.h is located in lua5.1/lua.h or lua5.0/lua.h, not under the main /usr/include. Yeh. My bad. I either need to remove it from the bootstrap or support it in the bootstrap then that error should go away. For the regular cmake build (aka post bootstrap/windows) it is in the tree so it is easy. - The approach of a single cmCommand.cxx to parse functions is probably limiting as it makes it harder to make the command syntax more flexible. The LuaFunction is an ivar and can be overridden in subclasses. This is how I made get_property a function that returns a value. See cmGetProperty.cxx for an example of this. Thanks Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake with Lua Experiment
I doubt seriously we will adopt a second language in CMake. There is no question of maintaining the current language. It has to and will be kept in CMake. It was very easy to add Lua to CMake which is nice (literally it was probably 15 hours of effort). Part of this experiment was to see if it was even programtically practical to add a second language. It turns out it is. Doing a complete nice integration would be pretty easy except for variables and syntax. That is where the two approaches significantly differ and as others have posted that is one place where CMake currently does not scale well. For those of us accustomed to functions and local variables the macro command is not quite right. We do need to address the variable/scope issue in CMake and I am sure we will. Starting from scratch I would use Lua for all the benefits a mature language provides, but adding it (or transitioning to it) I *suspect* is not worth it. (although part of me thinks in the long ten-year-out view it is worth it) Sometimes these issues take a while to gel. Ken Ken Martin PhD Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 11:35 AM, Ken Martin [EMAIL PROTECTED] wrote: I doubt seriously we will adopt a second language in CMake. There is no question of maintaining the current language. It has to and will be kept in CMake. It was very easy to add Lua to CMake which is nice (literally it was probably 15 hours of effort). Part of this experiment was to see if it was even programtically practical to add a second language. It turns out it is. Doing a complete nice integration would be pretty easy except for variables and syntax. That is where the two approaches significantly differ and as others have posted that is one place where CMake currently does not scale well. For those of us accustomed to functions and local variables the macro command is not quite right. We do need to address the variable/scope issue in CMake and I am sure we will. Starting from scratch I would use Lua for all the benefits a mature language provides, but adding it (or transitioning to it) I *suspect* is not worth it. (although part of me thinks in the long ten-year-out view it is worth it) Sometimes these issues take a while to gel. Sounds like me arguing with myself about whether I could adopt a dog. Oh I live in a tiny apartment. Well that didn't turn out to be important. I think the syntax for any CMake embedded language has to handle variable length input. Lists of stuff are so common in a build system that the language should handle them gracefully. I don't know enough about Lua to know whether this is natural in it. It's definitely not natural in C++ and I wouldn't choose C++ for specifying a build system. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 26, 2007 3:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
I noticed the unpack command.
sources = {
simpleLib.cxx,
simpleCLib.c,
simpleWe.cpp
}
cm_add_library (simpleLib, STATIC, unpack(sources));
Would this be necessary / paradigmatic in Lua? In CMake I just use lists.
Reading the Lua docs, it seems one uses a table instead of a list.
There's a shorthand for calling a function that has 1 table as its
argument: f{whatever} instead of f({whatever}). So I think the above
could have been:
cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp}
and of course the function would have to handle the table
appropriately. Now I'll see if we can get rid of all those pointless
quotes.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 2:32 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
On Nov 26, 2007 3:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
I noticed the unpack command.
sources = {
simpleLib.cxx,
simpleCLib.c,
simpleWe.cpp
}
cm_add_library (simpleLib, STATIC, unpack(sources));
Would this be necessary / paradigmatic in Lua? In CMake I just use lists.
Reading the Lua docs, it seems one uses a table instead of a list.
There's a shorthand for calling a function that has 1 table as its
argument: f{whatever} instead of f({whatever}). So I think the above
could have been:
cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp}
and of course the function would have to handle the table
appropriately.
Lua also has a varargs interface via ... so there's no reason this has
to be done with a table. But I guess you knew that already. So, the
real wart is that in CMake we only have to type ${sources} and in Lua
we'd have to type unpack(sources) all the time. That's gonna get old.
Now I'll see if we can get rid of all those pointless quotes.
It doesn't look possible. That's annoying.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Brandon Van Every wrote:
On Nov 27, 2007 2:32 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
On Nov 26, 2007 3:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
I noticed the unpack command.
sources = {
simpleLib.cxx,
simpleCLib.c,
simpleWe.cpp
}
cm_add_library (simpleLib, STATIC, unpack(sources));
Would this be necessary / paradigmatic in Lua? In CMake I just use lists.
Reading the Lua docs, it seems one uses a table instead of a list.
There's a shorthand for calling a function that has 1 table as its
argument: f{whatever} instead of f({whatever}). So I think the above
could have been:
cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp}
and of course the function would have to handle the table
appropriately.
Lua also has a varargs interface via ... so there's no reason this has
to be done with a table. But I guess you knew that already. So, the
real wart is that in CMake we only have to type ${sources} and in Lua
we'd have to type unpack(sources) all the time. That's gonna get old.
Now I'll see if we can get rid of all those pointless quotes.
It doesn't look possible. That's annoying.
How about?
cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
Regards,
Juan
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] CMake with Lua Experiment
Quoting Ken Martin [EMAIL PROTECTED]: I doubt seriously we will adopt a second language in CMake. There is no question of maintaining the current language. It has to and will be kept in CMake. It was very easy to add Lua to CMake which is nice (literally it was probably 15 hours of effort). Part of this experiment was to see if it was even programtically practical to add a second language. It turns out it is. Doing a complete nice integration would be pretty easy except for variables and syntax. That is where the two approaches significantly differ and as others have posted that is one place where CMake currently does not scale well. For those of us accustomed to functions and local variables the macro command is not quite right. We do need to address the variable/scope issue in CMake and I am sure we will. Starting from scratch I would use Lua for all the benefits a mature language provides, but adding it (or transitioning to it) I *suspect* is not worth it. (although part of me thinks in the long ten-year-out view it is worth it) Sometimes these issues take a while to gel. Just to make it totally clear as I was the one who tell you off: if the future of CMake is Lua, then I am totally in and for it. But in that case, please, please remove the current language. Every time someone creates a new Linux distribution, database engine or programming language to unify them all, it's a new one I have to learn and support. About regular expressions, I have started an implementation of regular expressions using PCRE 7.4 and the official PCRE C++ bindings (the ones contributed by Google last year). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Tuesday 27 November 2007, Juan Sanchez wrote:
...
How about?
cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
Are you sure putting it all in one quoted string will make getting the quoting
right simpler than it is now ?
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Alexander Neundorf wrote:
On Tuesday 27 November 2007, Juan Sanchez wrote:
...
How about?
cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
Are you sure putting it all in one quoted string will make getting the
quoting
right simpler than it is now ?
Please remember the context:
On Nov 27, 2007 2:32 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp}
.
.
.
.
Now I'll see if we can get rid of all those pointless quotes.
I was specifically talking about the lua api and offer suggestions
concerning Brandon's dislike for quotation marks and commas. Of course
cmake's current language is simpler. The goal of course is to have a
language which is well documented, popular, self-consistent, and not
home-made.
Of course, I'd much prefer Tcl, but everyone else hates it. However, if
Lua takes off, it will be much better than what we have now.
Juan
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Brandon Van Every wrote:
On Nov 27, 2007 3:22 PM, Juan Sanchez [EMAIL PROTECTED] wrote:
How about?
cm_add_library{simpleLib STATIC simpleLib.cxx simpleCLib.c simpleWe.cpp}
That paradigm is crippled with respect to FOREACH and LIST style
processing. I can't really see everyone on the CMake script side of
things doing it one way, and the Lua side of things doing it another
way. Plus it doesn't help for strings within strings.
I'm starting to realize that general purpose programming languages
don't care about ease of string entry. Whereas shell / make / build
tools have a history of making strings easy at the expense of other
programming constructs.
The reason I suggested Tcl was it makes strings easy. Most everything
is a string in Tcl. There are also no commas, parenthesis, or quotation
marks. Everyone hates Tcl, and I accept that.
For those of you who don't know enough about Tcl to hate it, please
check out:
http://en.wikipedia.org/wiki/Tcl#Syntax
My only desire is that we move on to another language better than the
one we have now. Lua seems to fit the bill.
Juan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 3:50 PM, Juan Sanchez [EMAIL PROTECTED] wrote: The goal of course is to have a language which is well documented, Yep. popular, Or at least not unpopular. There's a perception that TCL has lost the scripting wars. self-consistent, Yep. and not home-made. Well, there are quality and maintenance tradeoffs here. Someone else's language ain't that great if it's a PITA to use. if Lua takes off, it will be much better than what we have now. I'm not convinced. I'd like to see an acutal Lua build system, to get an idea just how many quotes and unpack() statements I'd likely be typing. Googling... Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007, at 4:08 PM, Brandon Van Every wrote: On Nov 27, 2007 3:50 PM, Juan Sanchez [EMAIL PROTECTED] wrote: The goal of course is to have a language which is well documented, Yep. popular, Or at least not unpopular. There's a perception that TCL has lost the scripting wars. self-consistent, Yep. and not home-made. Well, there are quality and maintenance tradeoffs here. Someone else's language ain't that great if it's a PITA to use. if Lua takes off, it will be much better than what we have now. I'm not convinced. I'd like to see an acutal Lua build system, to get an idea just how many quotes and unpack() statements I'd likely be typing. Googling... Cheers, Brandon Van Every How about we give the cmake developers some time to address some of the shortcomings of CMake BEFORE we toss the baby out with the bath water... -- Mike Jackson Senior Research Engineer Innovative Management Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
At 11/27/2007 04:02 PM, Juan Sanchez wrote: The reason I suggested Tcl was it makes strings easy. Most everything is a string in Tcl. Everything is a string in Tcl :) I'm not a Tcl noob, and things are not *that* easy in Tcl: when you have to throw an eval now and then, you know someone else is going to be in trouble understanding that code. There are also no commas, parenthesis, or quotation marks. Everyone hates Tcl, and I accept that. We don't hate Tcl at Kitware, we have been using Tcl for a long long time actually. VTK, our first (and probably largest) OpenSource product was wrapped pretty early on for that language (before Python or Java), and it was a satisfying experience; I remember prototyping VTK projects using Tcl almost 10 years ago, good times. We actually still rely heavily on Tcl/Tk for newer projects like KWWidgets (http://kwwidgets.org), we are compiling/rolling on own Tcl/Tk distrib internally every night for more than a few commercial products, and most of our testing is done in Tcl. See. Bill Hoffman said it last week: we have plenty of experience with Tcl, and it was specifically avoided in CMake from the start, probably for that reason :) This is way too big of a dependency for a build system like CMake. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 4:02 PM, Juan Sanchez [EMAIL PROTECTED] wrote: My only desire is that we move on to another language better than the one we have now. Lua seems to fit the bill. Just realized an interesting argument *not* to use an off-the-shelf language. Over the long haul, you lose control over the installed base. From the SCons FAQ: http://www.scons.org/faq.php#SS_3_6 3.6. Why is SCons written for Python version 1.5.2? Python 1.5.2 is still in widespread use on many systems, and was the version shipped by Red Hat as late as Red Hat 7.3. By writing the internal code so that it works on these systems, we're making it as easy as possible for more sites to install and work with SCons on as wide a variety of systems as possible. Why don't people just upgrade their Python version? you may ask. Yes, Python's packaging and installation make it easy for people to upgrade versions, but that's not the only barrier. In commercial development environments, any new operating system or language version must usually be accompanied by extensive tests to make sure that the upgrade hasn't introduced subtle problems or regressions into the code being produced. Consequently, upgrading is an expensive proposition that many sites can't undertake just because a new tool like SCons might require it. When faced with that sort of choice, it's much less risky and expensive for them to just walk away from trying the new tool. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 4:25 PM, Mike Jackson [EMAIL PROTECTED] wrote: How about we give the cmake developers some time to address some of the shortcomings of CMake BEFORE we toss the baby out with the bath water... Sounds good to me. Let's see where CMake is 6 months from now, with respect to scoping and documentation. While ruminating over Lua, I ran into cmake-promote arguments about Lua from almost 2 years ago. Something about a Lua front end for SCons called Hamster. Well, it's 1 guy's effort, it's GPLed, and the project page doesn't have any online documentation. CMake may be lacking in some areas, but it's worth considering where the competition is at. So I went to SCons to try to find the old SCons vs. everybody else page, and I found the bit in the FAQ about it being based on Python 1.5.2. I wonder if SCons loses Pythonistas because it uses an old Python? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
I think you are misinterpreting some things about the Lua syntax.
The heart and soul of Lua is the 'table'. It is *the* data structure
in Lua. A table is an hash or associative array. But in Lua, a table
can also be an array. There are some very interesting optimizations
under the hood that make sure both array and hash usage are extremely
fast (demonstrated by real world use and benchmarks).
So when you say 'list', think of a table in Lua.
Your example gets into some syntactic sugar:
cm_add_library{simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp}
This is actually just syntactic sugar for a function call without the
parenthesis that takes one table parameter that is inlined using the
table constructor syntax:
First add back the parenthesis for the function call:
cm_add_library( {simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp} )
Then, pull out the inline:
my_table = {simpleLib, STATIC, simpleLib.cxx,
simpleCLib.c,simpleWe.cpp}
cm_add_library(my_table)
These are all equivalent.
As you discovered Lua supports varargs. Lua is also dynamic so you can
check the types of the arguments passed in. This would allow you to
group things in different ways, allowing people the control of
deciding what is more natural.
So we can compare to our original call:
sources = {simpleLib.cxx, simpleCLib.c, simpleWe.cpp}
cm_add_library( simpleLib, STATIC, sources)
This is passing two string parameters, and a table containing the
sources. I think it is more natural to have a separate list/table for
sources, rather than combining it into one giant table as above. But
it is certainly possible to handle both cases.
We could also inline the thing like:
cm_add_library( simpleLib, STATIC, {simpleLib.cxx,
simpleCLib.c, simpleWe.cpp})
which is identical to the above.
Or we could exploit the varargs capability and not even use a table
and just list things one by one:
cm_add_library( simpleLib, STATIC, simpleLib.cxx,
simpleCLib.c, simpleWe.cpp)
This is actually what unpack(sources) was doing. Unpack was basically
flattening/unpacking the table and passing each element in the table
as a separate parameter. Lua's varargs ability automatically kicks in
and unrolls the thing. As I said, the use of unpack() was
unnecessary.
Lua can also do other some interesting things besides tables. Like
most other languages, you could also invoke a function call.
-- Return a table containing the sources
function GetSources()
return { simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp }
end
cm_add_library( simpleLib, STATIC, GetSources())
Lua supports multiple return arguments too so one could return all the
elements instead:
-- Instead of returning 1 table, return 3 strings
function GetSources()
return simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp
end
cm_add_library( simpleLib, STATIC, GetSources())
You can also inline functions and make them anonymous:
cm_add_library( simpleLib, STATIC, function () return simpleLib,
STATIC, simpleLib.cxx, simpleCLib.c, simpleWe.cpp end )
(Quick note, for demonstration purposes, here we are actually passing
the function reference, not invoking unlike the previous examples.
cm_add_library could then detect the type is a function and invoke it
for us. To invoke it, add () right after 'end'.)
You can also use function pointers/objects/closures.
function GetSources()
return simpleLib, STATIC, simpleLib.cxx, simpleCLib.c,
simpleWe.cpp
end
my_function = GetSources
cm_add_library( simpleLib, STATIC, my_function)
(Again, I am not invoking the function, and it could be invoked by
cm_add_library. Do my_function() to invoke.)
Obviously, you might have different criteria to decide what
my_function actually represents. (Maybe Windows and Linux have
different sources.)
Closures can get very interesting because you can inject the
appearance of state into your function calls. This would probably only
be used by people in very specific circumstances. One random thought
is maybe you have some file generation stuff going on in your build
system, and with every call of my_function, you need to increment a
unique number suffix to the a file. (See newCounter example at
http://www.lua.org/pil/6.1.html).
That paradigm is crippled with respect to FOREACH and LIST style processing.
I'm not completely sure what you are after here, but Lua also has a
for/foreach construct for tables so you can use that too. And it is
potentially very powerful because you can write your own iterator
functions/criteria.
An additional thought is to export global constants (variables), so we
can basically create keywords. So instead of:
cm_add_library( simpleLib, STATIC, sources)
we could drop the quotes around STATIC:
cm_add_library( simpleLib, STATIC, sources)
(We also might consider namespacing the keywords: CM.STATIC.)
3.6. Why is SCons written for Python version 1.5.2?
That's an interesting and legitimate point. With Lua, though, the
issues are a
Re: [CMake] CMake with Lua Experiment
On Nov 27, 2007 10:13 PM, E. Wing [EMAIL PROTECTED] wrote:
I think you are misinterpreting some things about the Lua syntax.
My understanding of Lua syntax improved greatly after reading the
docs for 15 minutes.
Or we could exploit the varargs capability and not even use a table
and just list things one by one:
cm_add_library( simpleLib, STATIC, simpleLib.cxx,
simpleCLib.c, simpleWe.cpp)
The programmer desired to use a variable. In CMake script we would write
add_library(simpleLib STATIC ${sources})
This is actually what unpack(sources) was doing. Unpack was basically
flattening/unpacking the table and passing each element in the table
as a separate parameter.
(Aside: what's with the cm_ prefix?) In Lua we could write:
add_library(simpleLib, STATIC, unpack(sources))
I consider the quoting and the unpack() to be more verbose. The
commas don't bug me, I think because I don't have to hit SHIFT to type
them.
Lua's varargs ability automatically kicks in
and unrolls the thing. As I said, the use of unpack() was
unnecessary.
I'm doubting that's correct. I doubt that sources and unpack(sources)
are the same thing at all. Pretty unreasonable for a language to
treat a variable representing a table, and the expansion of the table,
as exactly the same thing. In CMake script, a LIST and a ${LIST} are
not the same thing.
That paradigm is crippled with respect to FOREACH and LIST style processing.
I'm not completely sure what you are after here, but Lua also has a
for/foreach construct for tables so you can use that too.
Yes I know. I was saying that passing file1.c file2.c file3.c is
not a solution to Lua's excessive quoting problem, because you'd be
sacrificing desireable processing capabilities. We want to be able to
operate on lists/tables of stuff with FOREACH, LIST, individuated
parameters, and so forth.
3.6. Why is SCons written for Python version 1.5.2?
That's an interesting and legitimate point. With Lua, though, the
issues are a little different. If CMake adopts Lua, then it should be
embedded with CMake (especially since it is not standard with Windows
and Mac). Because you embed Lua, the CMake authors have complete say
on which version is used and is not influenced by what the most
popular Linux distro has installed and is available to the masses. So
CMake has final discretion over which version is used.
The point is that the marketing luster of Lua will fade. The legacy
CMake builds will all be using an old, hoary version of Lua. CMake
will have to support those old builds to some degree. It won't be
able to utilize newfangled Lua stuff, if the newfangled stuff breaks
backwards compatibility. I bet there are problems between Python
1.5.2 and 2.5.1, although I'm not up on them. I bet the Python
community doesn't consider Python 1.5.2 a sales point, if they stare
closely at SCons. Now, people may not stare closely. And in any
event, the luster of Lua will probably last 5 years. But then it'll
be over, and the real question will be, was it a cool choice for text
processing? 'Cuz that's what a build system mostly is.
What we really want is Ruby without the licensing hassles. And a bit faster.
An additional thought is to export global constants (variables), so we
can basically create keywords. So instead of:
cm_add_library( simpleLib, STATIC, sources)
we could drop the quotes around STATIC:
cm_add_library( simpleLib, STATIC, sources)
That's an improvement.
I wish we could get rid of quotes in places that don't need them. How
easy would it be to modify Lua in that regard? So, CMake would be a
Lua variant rather than straight Lua. But it would still be 95% the
same, and Lua quotes would work as documented... you just wouldn't
always need them. Most of the marketing value of Lua would be
retained. And that marketing value isn't permanent anyways. Only
drawback I see, is I suppose quoteless Lua strings might bugger third
party Lua libraries, unless some nice marshaling to external libraries
is possible.
If Lua has some kind of preprocessor, it would be trivial to regex the
input file for certain string types, then add the quotes to keep Lua
happy. If it can't be done then throw an error about lack of quotes.
The docs would have a teeny tiny addendum to describe the Lua dialect.
Such mods shouldn't be culturally verboten to Lua people anyways.
It's supposed to be an embeddable and customizable language.
(We also might consider namespacing the keywords: CM.STATIC.)
No. It's a build system and Lua is the embedded language to serve the
build system. That's the context for anything anyone is ever gonna
do. The cm_ prefixes should go bye-bye. Constants in CMake script
should be exactly the same as constants in Lua script. It should be
trivial for a CMake script veteran to pick up CMake Lua, and wherever
possible, it shouldn't give the CMake script veteran a rash. It
should be an obvious and desireable migration path; otherwise, what's
the
Re: [CMake] CMake with Lua Experiment
Hi CMakers! Being relatively new to CMake (3 months now), this whole LUA discussion seems very odd ... (so please accept an apology for my ignorance in advance) An additional thought is to export global constants (variables), so we can basically create keywords. So instead of: cm_add_library( simpleLib, STATIC, sources) we could drop the quotes around STATIC: cm_add_library( simpleLib, STATIC, sources) Maybe I am missing the obvious, but I am trying to understand -why- this list is talking about replacing the current CMake language. As it seems everyone is trying to retrofit the would be new language to be just like the current language. I do understand the want (need?) to retain backwards compatibility, but a fork-lift replacment of the current language sounds like a bad idea; if that is indeed the goal. Thanks, George. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 12:56 AM, George Neill [EMAIL PROTECTED] wrote: Maybe I am missing the obvious, but I am trying to understand -why- this list is talking about replacing the current CMake language. - better scoping - higher quality, outsourced documentation - outsource core language bugs - popularity boost for 5 years - some advanced programming constructs gained Anyone want to add to this? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Brandon, On 11/28/07, Brandon Van Every [EMAIL PROTECTED] wrote: - better scoping - higher quality, outsourced documentation - outsource core language bugs - popularity boost for 5 years - some advanced programming constructs gained I certainly can't debate those (unless CMake developers make significant changes to the core LUA libraries). Is backward compatibility with the current language a goal of the LUA experiment? I ask because the examples spoken of on this list appear to be trying to mimic the current CMake syntax. Thanks, George. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 1:16 AM, Sebastien BARRE [EMAIL PROTECTED] wrote: At 11/28/2007 01:06 AM, Brandon Van Every wrote: On Nov 28, 2007 12:56 AM, George Neill [EMAIL PROTECTED] wrote: Maybe I am missing the obvious, but I am trying to understand -why- this list is talking about replacing the current CMake language. - popularity boost for 5 years woot? Nobody cares about CMake script. Losta people care about Lua. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Quoting Brandon Van Every [EMAIL PROTECTED]: On Nov 28, 2007 1:16 AM, Sebastien BARRE [EMAIL PROTECTED] wrote: At 11/28/2007 01:06 AM, Brandon Van Every wrote: On Nov 28, 2007 12:56 AM, George Neill [EMAIL PROTECTED] wrote: Maybe I am missing the obvious, but I am trying to understand -why- this list is talking about replacing the current CMake language. - popularity boost for 5 years woot? Nobody cares about CMake script. Losta people care about Lua. People are assuming stock Lua would be used but I am not so sure about that. I guess it would actually be a domain-specific language based on Lua: some specific commands and constructs would be needed (sure, they would be implemented in Lua or whatever, but you would need to document that). As DSL based on Lua != Lua, assuming Kitware gets rid of documentation and bugs in the language might be too optimistic. Look for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based DSL for hardware description, like Verilog or VHDL, but it's so different from Ruby you need to produce the whole documentation again. Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 1:48 AM, George Neill [EMAIL PROTECTED] wrote:
On 11/28/07, Brandon Van Every [EMAIL PROTECTED] wrote:
- better scoping
- higher quality, outsourced documentation
- outsource core language bugs
- popularity boost for 5 years
- some advanced programming constructs gained
I certainly can't debate those (unless CMake developers make significant
changes to the core LUA libraries).
Is backward compatibility with the current language a goal of the LUA
experiment? I ask because the examples spoken of on this list appear to be
trying to mimic the current CMake syntax.
I think mimicry is a goal to some degree, so that CMake script
veterans are comfortable with migrating, and so that knowledge of how
to use CMake is not indelibly split into 2 camps. For instance, a
list in CMake script is a table in Lua is an important paradigm to
maintain. I think there should be no difference whatsoever in CMake
command, constant, and variable names. If I want to cut 'n' paste
CMake script code to Lua code, or vice versa, I should be able to get
away with the minimum of fiddling. In fact, the conventions should be
so similar that a CMake script -- Lua converter should be trivial to
write. Some CMake veterans have kicked and screamed about having to
learn something new. My thought is, there really shouldn't be
anything to learn. I mean, after reading the Lua docs for 15 minutes,
it's almost obvious how CMake Lua *could* be done, *if* a couple of
warts are removed.
I don't think there's any meaningful way to talk about backwards
compatibility from Lua to CMake script. I did raise some issues
about Lua now vs. Lua 5 years from now. We see that SCons is on
Python 1.5.2. That will happen to CMake with regards to Lua.
What I'm now interested in, is the degree to which Lua can be
customized as a Domain Specific Language, so that CMake can control
its own fate. Specifically, I'd like to see excessive quoting go
bye-bye. I'd also like a shorter way to dereference a table than
unpack(table). ${table} would work for me, although I don't know how
well it would be received in the Lua community.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 26, 2007 1:18 PM, Ken Martin [EMAIL PROTECTED] wrote:
Just heading down this path as an experiment to get a better feel for it.
Posted a snapshot of the source code on the Wiki
http://www.cmake.org/Wiki/CMake:Experiments_With_Lua The biggest issues I
see are 1) keeping two languages around sounds like more work and who needs
more work 2) variables in lua are not variables in CMake and vice versa.
The cm_configure_file command only configures cmake variables, this could be
a good thing in one sense :)
I noticed the unpack command.
sources = {
simpleLib.cxx,
simpleCLib.c,
simpleWe.cpp
}
cm_add_library (simpleLib, STATIC, unpack(sources));
Would this be necessary / paradigmatic in Lua? In CMake I just use lists.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Quoting Ken Martin [EMAIL PROTECTED]: Just heading down this path as an experiment to get a better feel for it. Posted a snapshot of the source code on the Wiki http://www.cmake.org/Wiki/CMake:Experiments_With_Lua The biggest issues I see are 1) keeping two languages around sounds like more work and who needs more work 2) variables in lua are not variables in CMake and vice versa. The cm_configure_file command only configures cmake variables, this could be a good thing in one sense :) I do not mean to be rude, but please scrap it. Or make Lua the only language allowed in CMake. But having two languages is going to be bad because in the end, we will need to know and at least be able to understand two languages as there will be CMakeLists.txt, Find.cmake, etc files in both languages. Before Lua is added as a language to CMake, I'd like to ask a question: is there really a need for Lua (or any other language) or is the current CMake scripting Turing-complete and able to do anything which could be done with Lua? Please note I'm not against Lua but only against having to know two languages. Thank you. -- 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
