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
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: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
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
[CMake] installing generated files
Hi,
how to install files generated by custom targets, eg. doxygen? The files are
generated in ${DOXYGEN_BINARY_DIR}/html ( /doc/html ).
here is the /doc/CMakeLists.txt
##
PROJECT(doxygen)
FIND_PACKAGE(Doxygen REQUIRED)
CONFIGURE_FILE(${doxygen_SOURCE_DIR}/Doxyfile.in
${doxygen_BINARY_DIR}/Doxyfile)
FILE(MAKE_DIRECTORY ${doxygen_BINARY_DIR}/html)
ADD_CUSTOM_TARGET(docs-doxygen COMMAND ${DOXYGEN_EXECUTABLE}
${doxygen_BINARY_DIR}/Doxyfile VERBATIM)
INSTALL(DIRECTORY ${doxygen_BINARY_DIR}/html DESTINATION ${PERTUBIS_DOC_PATH})
##
Stefan Kögl
signature.asc
Description: This is a digitally signed message part.
___
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
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 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 obviou
Re: [CMake] CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS available in version X?
On Nov 27, 2007, at 3:14 PM, Filipe Sousa wrote: James Bigler wrote: I just noticed this Wiki entry. What version of CMake was this introduced in? It's not mentioned in any of the help files, so I can't track when it was introduced. http://www.cmake.org/Wiki/CMake_FAQ#Isn.27t_the_.22Expression. 22_in_the_.22ELSE_.28Expression.29.22_confusing.3F SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true) 2.4.3 Thanks for the response! James ___ 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 SC
Re: [CMake] CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS available in version X?
James Bigler wrote: > I just noticed this Wiki entry. What version of CMake was this > introduced in? It's not mentioned in any of the help files, so I > can't track when it was introduced. > > http://www.cmake.org/Wiki/CMake_FAQ#Isn.27t_the_.22Expression. > 22_in_the_.22ELSE_.28Expression.29.22_confusing.3F > > SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true) 2.4.3 signature.asc Description: OpenPGP digital signature ___ 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
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
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, 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
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
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: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.
Cheers,
Brandon Van Every
___
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] Patch to FindQt4.cmake for supporting moc compiler options
On 11/27/07, clinton wrote:
> On Saturday 24 November 2007 3:23:16 pm Miguel A. Figueroa-Villanueva wrote:
> > Hello,
> >
> > I would like to propose the following patch or something similar to
> > add support for moc compiler options. Currently, one can do the
> > following:
> >
> > SET(moc-sources foo.h bar.h)
> > QT4_WRAP_CPP(sources ${moc-sources})
> >
> > With the attached patch one could pass also options to be invoked with
> > each moc-source:
> >
> > QT4_WRAP_CPP(sources ${moc-sources} OPTIONS -DMYDEF)
> >
> > The current approach is a simplified one to support the following syntax:
> >
> > QT4_WRAP_CPP( [OPTIONS opt1 opt2 ...])
> >
> > This could also be applied to QT4_WRAP_UI(...).
> >
> > --Miguel
>
> I'm curious what the convention is for adding arguments to custom commands in
> macros.
Don't know... But I looked at how cmake commands work and tried to
provide something along those lines.
> To compare, I see the FindSWIG.cmake/UseSWIG.cmake allow setting the
> CMAKE_SWIG_FLAGS variable. The advantage of that is that it applies to all
> calls of the macro.
The problem I see with this is that you depend on the value of say
QT4_MOC_FLAGS and then scoping issues come into play. For example, if
you set this flag then in a later call you will have it affect that
call unintentionally unless you clear it. It's then complicated when
you consider INCLUDE files. So, my thoughts were to send the options
to the macro every time you need them and not worry about the variable
scope ramifications and other use cases.
Just my two cents,
--Miguel
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Trouble with interdependent libraries
I'm working with 3 CMakeLists.txt files I didn't write, so I'm trying to figure out the reasoning behind them. -Application A has a CMakeLists.txt file with TARGET_LINK_LIBARIES(LibB, LibC). -LibB and LibC each have their own subfolders and CMakeLists.txt file, and use ADD_LIBRARY to declare their sources to be a library. -LibB uses some classes defined in LibC. Under windows, I can run cmake, compile and link without errors. On Linux, I get linker errors that LibB's uses of LibC are undefined references. I tried adding TARGET_LINK_LIBRARY(LibC) to LibB's CMakeLists.txt file, but that didn't fix the error. Any ideas? ___ 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
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] FindQt3.cmake bug - does not recognize uic
Hi!
Unfortunately, I do not have any small project using cmake.
I will make some if needed.
I tried it on Fedora w/ CMake CVS.
uic -version gives me
"User Interface Compiler for Qt version 3.3.8"
What if you change the regex to this?
IF("${QTVERSION_UIC}" MATCHES ".* 3\\..*")
I tried this,
did not work.
And did you check that the QT_UIC_EXECUTABLE in your CMakeCache.txt file is
indeed a Qt3's uic (now that you mention some are not installed properly)?
Yes, it shows a proper path. On my system, I have only Qt3 and well
installed.
Thanks!
Anka
___
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
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
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
[CMake] Re: [Dart] Dart2 issue and future
Bah, wrong mailing list, sorry. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: [Dart] Dart2 issue and future
On Nov 27, 2007 1:34 PM, Félix C. Morency <[EMAIL PROTECTED]> wrote: > Hi, > > I have another issue with Dart2. Every timestamp is fixed to > "theCurrentDay/theCurrentMonth/theCurrentYear 20:00". Actually the problem > is that the build hour is always 20:00. > > I also have other questions/recommandations: > > 1) Is Dart2 currently developped ? If yes, by who ? http://www.na-mic.org/Wiki/index.php/Dart2Summary This weblink is hard to find. There's a teeny tiny footnote about it on the http://public.kitware.com/Dart/HTML/About.shtml page. I recommended a much more general cleanup of the Kitware Dart webpages several months ago. For instance, I see that the Kitware Dart FAQ is listed as "currently unavailable," i.e. it was never written. I recommended that the "News" page be deleted, as it talks about things that "will happen in 2001," which is exceedingly unprofessional marketing. I'm sure there are other things I recommended that weren't done. Oh well, not my problem. If Dart looks like Deathware than so be it. Cheers, Brandon Van Every > 2) It would be a good idea to open a bug tracker dedicated to Dart2. > 3) It would also be a good idea to have a dedicated Dart2 webpage. > > I think Dart2 is a nice product but lacks some basic elements. Feel free to > add your comments. > > Regards > Félix C. Morency > > > > ___ > Dart mailing list > [EMAIL PROTECTED] > http://public.kitware.com/mailman/listinfo/dart > > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt3.cmake bug - does not recognize uic
On Tuesday 27 November 2007 10:52:55 am Anka Kochanowska wrote:
> Thanks for answering.
> Our application is built on different systems. Some of them have Qt3 and
> Qt4, some have not been properly installed, so having the condition
> would be helpful to diagnose the problem.
> FindQt3.cmake fails on Ubuntu, Debian and Mandrake. So we comment out
> the condition, but ...
> Also, there is no problem with moc and it is treated pretty much the
> same way as uic.
> What is your system?
I tried it on Fedora w/ CMake CVS.
uic -version gives me
"User Interface Compiler for Qt version 3.3.8"
What if you change the regex to this?
IF("${QTVERSION_UIC}" MATCHES ".* 3\\..*")
And did you check that the QT_UIC_EXECUTABLE in your CMakeCache.txt file is
indeed a Qt3's uic (now that you mention some are not installed properly)?
Clint
>
> Anka
>
> [EMAIL PROTECTED] wrote:
> >On Tuesday 27 November 2007 8:21:38 am Anka Kochanowska wrote:
> >>Hi!
> >>I am using Qt3 (3.3.3)
> >>In my CMakeList.txt I have conditionals:
> >>
> >>IF(QT_WRAP_UI)
> >> QT_WRAP_UI( Basic IGNS_BASIC_HDR IGNS_BASIC_SRC ${IGNS_BASIC_GUI_SRC} )
> >>ENDIF(QT_WRAP_UI)
> >>
> >>This used to work still in CMake 2.4 patch 3. Since themn, the
> >>FindQt3.cmake has been changed and it does not
> >>recognize uic.
> >>
> >>
> >>There is a problem with the following code:
> >>
> >>EXEC_PROGRAM(${QT_UIC_EXECUTABLE} ARGS "-version" OUTPUT_VARIABLE
> >>QTVERSION_UI)
> >>
> >>in my case QTVERSION_UI is:User Interface Compiler for Qt version
> >>3.3.3
> >>
> >>The following test:
> >>SET(_QT_UIC_VERSION_3 FALSE)
> >>IF("${QTVERSION_UIC}" MATCHES ".* 3..*")
> >> SET(_QT_UIC_VERSION_3 TRUE)
> >>ENDIF("${QTVERSION_UIC}" MATCHES ".* 3..*")
> >>
> >>sets QT_UIC_VERSION_3 to FALSE
> >>
> >>which causes the
> >>SET(QT_WRAP_UI FALSE)
> >>IF (QT_UIC_EXECUTABLE)
> >> IF(_QT_UIC_VERSION_3)
> >>SET ( QT_WRAP_UI TRUE)
> >> ENDIF(_QT_UIC_VERSION_3)
> >>ENDIF (QT_UIC_EXECUTABLE)
> >>
> >>returning QT_WRAP_UI as FALSE
> >>
> >>I do not know how to set the regex in order to find 3 in the version
> >>return by uic. I tried differnt things and miserably failed.
> >>
> >>Could anyone help, please?
> >>
> >>I have seen quite few postings about QT_WRAP_UI failure and the
> >>suggestions were either to drop the condition or to manually run uic
> >
> >I'm unable to reproduce this. Do you have a simple CMakeLists.txt file
> > that you can reproduce this with?
> >
> >I'm also curious why you conditionally run uic. Wouldn't your project
> > fail to build without that? Do you really want IF(QT_FOUND) instead?
> >
> >Clint
>
> ___
> 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] statically linked executables
Daniel Rueckert wrote: Hi, I am trying to build some statically linked executables on a linux box. I have added the "-static" option to the linker flags and specified static link libraries but for some reason cmake still adds the option "-Wl,-Bdynamic" flag to the linker options. Is there any way around this? Thanks, Daniel Sounds like you might have some explicit shared libraries linked into you project with full paths. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt3.cmake bug - does not recognize uic
Thanks for answering.
Our application is built on different systems. Some of them have Qt3 and
Qt4, some have not been properly installed, so having the condition
would be helpful to diagnose the problem.
FindQt3.cmake fails on Ubuntu, Debian and Mandrake. So we comment out
the condition, but ...
Also, there is no problem with moc and it is treated pretty much the
same way as uic.
What is your system?
Anka
[EMAIL PROTECTED] wrote:
On Tuesday 27 November 2007 8:21:38 am Anka Kochanowska wrote:
Hi!
I am using Qt3 (3.3.3)
In my CMakeList.txt I have conditionals:
IF(QT_WRAP_UI)
QT_WRAP_UI( Basic IGNS_BASIC_HDR IGNS_BASIC_SRC ${IGNS_BASIC_GUI_SRC} )
ENDIF(QT_WRAP_UI)
This used to work still in CMake 2.4 patch 3. Since themn, the
FindQt3.cmake has been changed and it does not
recognize uic.
There is a problem with the following code:
EXEC_PROGRAM(${QT_UIC_EXECUTABLE} ARGS "-version" OUTPUT_VARIABLE
QTVERSION_UI)
in my case QTVERSION_UI is:User Interface Compiler for Qt version
3.3.3
The following test:
SET(_QT_UIC_VERSION_3 FALSE)
IF("${QTVERSION_UIC}" MATCHES ".* 3..*")
SET(_QT_UIC_VERSION_3 TRUE)
ENDIF("${QTVERSION_UIC}" MATCHES ".* 3..*")
sets QT_UIC_VERSION_3 to FALSE
which causes the
SET(QT_WRAP_UI FALSE)
IF (QT_UIC_EXECUTABLE)
IF(_QT_UIC_VERSION_3)
SET ( QT_WRAP_UI TRUE)
ENDIF(_QT_UIC_VERSION_3)
ENDIF (QT_UIC_EXECUTABLE)
returning QT_WRAP_UI as FALSE
I do not know how to set the regex in order to find 3 in the version
return by uic. I tried differnt things and miserably failed.
Could anyone help, please?
I have seen quite few postings about QT_WRAP_UI failure and the
suggestions were either to drop the condition or to manually run uic
I'm unable to reproduce this. Do you have a simple CMakeLists.txt file that
you can reproduce this with?
I'm also curious why you conditionally run uic. Wouldn't your project fail to
build without that? Do you really want IF(QT_FOUND) instead?
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to FindQt4.cmake for supporting moc compiler options
On Saturday 24 November 2007 3:23:16 pm Miguel A. Figueroa-Villanueva wrote:
> Hello,
>
> I would like to propose the following patch or something similar to
> add support for moc compiler options. Currently, one can do the
> following:
>
> SET(moc-sources foo.h bar.h)
> QT4_WRAP_CPP(sources ${moc-sources})
>
> With the attached patch one could pass also options to be invoked with
> each moc-source:
>
> QT4_WRAP_CPP(sources ${moc-sources} OPTIONS -DMYDEF)
>
> The current approach is a simplified one to support the following syntax:
>
> QT4_WRAP_CPP( [OPTIONS opt1 opt2 ...])
>
> This could also be applied to QT4_WRAP_UI(...).
>
> --Miguel
I'm curious what the convention is for adding arguments to custom commands in
macros.
To compare, I see the FindSWIG.cmake/UseSWIG.cmake allow setting the
CMAKE_SWIG_FLAGS variable. The advantage of that is that it applies to all
calls of the macro.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt3.cmake bug - does not recognize uic
On Tuesday 27 November 2007 8:21:38 am Anka Kochanowska wrote:
> Hi!
> I am using Qt3 (3.3.3)
> In my CMakeList.txt I have conditionals:
>
> IF(QT_WRAP_UI)
> QT_WRAP_UI( Basic IGNS_BASIC_HDR IGNS_BASIC_SRC ${IGNS_BASIC_GUI_SRC} )
> ENDIF(QT_WRAP_UI)
>
> This used to work still in CMake 2.4 patch 3. Since themn, the
> FindQt3.cmake has been changed and it does not
> recognize uic.
>
>
> There is a problem with the following code:
>
> EXEC_PROGRAM(${QT_UIC_EXECUTABLE} ARGS "-version" OUTPUT_VARIABLE
> QTVERSION_UI)
>
> in my case QTVERSION_UI is:User Interface Compiler for Qt version
> 3.3.3
>
> The following test:
> SET(_QT_UIC_VERSION_3 FALSE)
> IF("${QTVERSION_UIC}" MATCHES ".* 3..*")
> SET(_QT_UIC_VERSION_3 TRUE)
> ENDIF("${QTVERSION_UIC}" MATCHES ".* 3..*")
>
> sets QT_UIC_VERSION_3 to FALSE
>
> which causes the
> SET(QT_WRAP_UI FALSE)
> IF (QT_UIC_EXECUTABLE)
> IF(_QT_UIC_VERSION_3)
> SET ( QT_WRAP_UI TRUE)
> ENDIF(_QT_UIC_VERSION_3)
> ENDIF (QT_UIC_EXECUTABLE)
>
> returning QT_WRAP_UI as FALSE
>
> I do not know how to set the regex in order to find 3 in the version
> return by uic. I tried differnt things and miserably failed.
>
> Could anyone help, please?
>
> I have seen quite few postings about QT_WRAP_UI failure and the
> suggestions were either to drop the condition or to manually run uic
I'm unable to reproduce this. Do you have a simple CMakeLists.txt file that
you can reproduce this with?
I'm also curious why you conditionally run uic. Wouldn't your project fail to
build without that? Do you really want IF(QT_FOUND) instead?
Clint
___
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
[CMake] statically linked executables
Hi, I am trying to build some statically linked executables on a linux box. I have added the "-static" option to the linker flags and specified static link libraries but for some reason cmake still adds the option "-Wl,-Bdynamic" flag to the linker options. Is there any way around this? Thanks, Daniel -- Daniel Rueckert, Ph.D. Department of Computing Imperial College London 180 Queens' Gate Tel: +44 20 7594 8333 London SW7 2AZ Fax: +44 20 7581 8024 mailto:[EMAIL PROTECTED] http://www.doc.ic.ac.uk/~dr ___ 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
> - 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 > 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
[CMake] FindQt3.cmake bug - does not recognize uic
Hi!
I am using Qt3 (3.3.3)
In my CMakeList.txt I have conditionals:
IF(QT_WRAP_UI)
QT_WRAP_UI( Basic IGNS_BASIC_HDR IGNS_BASIC_SRC ${IGNS_BASIC_GUI_SRC} )
ENDIF(QT_WRAP_UI)
This used to work still in CMake 2.4 patch 3. Since themn, the
FindQt3.cmake has been changed and it does not
recognize uic.
There is a problem with the following code:
EXEC_PROGRAM(${QT_UIC_EXECUTABLE} ARGS "-version" OUTPUT_VARIABLE
QTVERSION_UI)
in my case QTVERSION_UI is:User Interface Compiler for Qt version
3.3.3
The following test:
SET(_QT_UIC_VERSION_3 FALSE)
IF("${QTVERSION_UIC}" MATCHES ".* 3..*")
SET(_QT_UIC_VERSION_3 TRUE)
ENDIF("${QTVERSION_UIC}" MATCHES ".* 3..*")
sets QT_UIC_VERSION_3 to FALSE
which causes the
SET(QT_WRAP_UI FALSE)
IF (QT_UIC_EXECUTABLE)
IF(_QT_UIC_VERSION_3)
SET ( QT_WRAP_UI TRUE)
ENDIF(_QT_UIC_VERSION_3)
ENDIF (QT_UIC_EXECUTABLE)
returning QT_WRAP_UI as FALSE
I do not know how to set the regex in order to find 3 in the version
return by uic. I tried differnt things and miserably failed.
Could anyone help, please?
I have seen quite few postings about QT_WRAP_UI failure and the
suggestions were either to drop the condition or to manually run uic
Thanks!
Anka
___
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 , 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
