> - 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
> but the bootstrap/cmakelists.xt does not search for paths to it. Under
> my Ubuntu box, lua.h is located in lua5.
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 sco
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
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
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-b
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
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 t
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 t
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/cmak
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
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 ab
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
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 prog
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
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
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 variabl
> 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
> 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 involve
> (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 d
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 desc
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 cons
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 under
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 abou
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 develop
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
-
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_li
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
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 s
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
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 cont
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 e
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 war
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, th
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 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
thing
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 ?
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
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). Pa
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"
>>> }
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 ("
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?
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
> pro
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
> - 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
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, a
Ken Martin 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 mor
On Nov 26, 2007 6:03 PM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote:
>
> 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 d
Let me second that. It seems that those usually unhappy with
something speak up and those that are happy stay quiet. This has the
unfortunate effect of making something look broke when it really is
not. Let me be loud also.
I DO NOT NEED ANOTHER LANGUAGE TO LEARN ALL THE NUANCES OF. I LIKE
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 wo
Brandon Van Every wrote:
> 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
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 lang
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
52 matches
Mail list logo
