On Saturday 01 March 2008, Miguel A. Figueroa-Villanueva wrote:
On Fri, Feb 29, 2008 at 11:09 AM, Bill Hoffman wrote:
Rodolfo Schulz de Lima wrote:
The main issue with CMake script isn't when writing a build script,
but when writing auxiliary stuff, like a more elaborate Find*.cmake.
On Mon, Mar 3, 2008 at 6:13 PM, James Mansion
[EMAIL PROTECTED] wrote:
Brandon Van Every wrote:
Then probably that is because those projects use Ruby AND Python AND Tcl
- so I have to have them anyway. Hey, lets all use C89. Everyone has
that, right?
What if it is just
Bill Hoffman wrote:
James Mansion wrote:
So, C++ is the language we picked/like. You are welcome to contribute
one in C++. Imagine if you could develop generators (I assume that is
what you mean by emitters) in any language! You wouldn't even be able
to share them.
Bill, I like C++ as much
James Mansion wrote:
Bill Hoffman wrote:
James Mansion wrote:
So, C++ is the language we picked/like. You are welcome to contribute
one in C++. Imagine if you could develop generators (I assume that is
what you mean by emitters) in any language! You wouldn't even be able
to share them.
At 3/2/2008 09:10 AM, James Mansion, wrote:
If I have a project that is largely in a more convenient language -
whether Java or Python or C# (or even Lua) - and it has material
components in C++ for performance or reuse reasons, then it is
clearly reasonable to ship something that can make a
On Sun, Mar 2, 2008 at 9:10 AM, James Mansion
[EMAIL PROTECTED] wrote:
Well, I suppose you don't have to use CMake. Perhaps scons would be a
better fit for your tastes.
In a Python-based system, yes.
But if I have a C++ code and a variety of value added components aimed
at
Hello everyone,
Sorry for the quick interruption, but somehow I have the feeling this
discussion will start again and again and again, if it has ever appeared
to end. Here are my two cents...
IMHO there might be a misunderstanding concerning Kitware's CMake
strategy: It is a domain specific
merit of Python, Ruby, or Lua over CMake
script has not been demonstrated, it is speaking to this very point.
Perhaps general purpose scripting *is* provably better for a large
scale build, but I would like to see a large scale project that proves
that, rather than assuming it.
From
Bill Hoffman wrote:
So what exactly about the CMake language gives you this feel?
That would be:
1) the syntax
and
2) the modularity constructs
I know its 'only' scripting to manage declarations into the engine.
Its a shame you can't write emitters except in C++ but that certainly
wouldn't
James Mansion wrote:
Bill Hoffman wrote:
So what exactly about the CMake language gives you this feel?
That would be:
1) the syntax
and
2) the modularity constructs
I know its 'only' scripting to manage declarations into the engine.
Its a shame you can't write emitters except in C++ but
On Fri, Feb 29, 2008 at 12:59 AM, Sebastien BARRE
[EMAIL PROTECTED] wrote:
Brandon wrote:
I'm willing to give Bill some time to think about the undoability
of CMake -- Lua translation
Great. And by some time you mean someday, therefore 2 years,
right.
Your style of communication
with 2 languages.
It really all depends on how far back the CMake compatibility has to go.
A far more likely scenario is, CMake -- Lua translators are used to
get 99% of the CMake community onto Lua. The remaining 1% contract
with Kitware for their special needs.
Cheers,
Brandon Van Every
Brandon Van Every wrote:
We're still at (1). I'm willing to drop discussion of CMake -- Lua
translators for 3 months, to give Bill time to think. *If* I don't
It really all depends on how far back the CMake compatibility has to go.
A far more likely scenario is, CMake -- Lua translators
James Mansion wrote:
Sebastien BARRE wrote:
Again: *deal*.
February 29th, 2010 *precisely*.
Special CMake/Lua day, the 29th.
That will indeed be a very special day.
Shame really. I like Lua, and I find that the CMake script language
seems designed to make COBOL coders feel they don't actually
if they
did, I would not want to invalidate there effort by obsoleting the
language they programmed in.
It would be much safer and easier to continue
to support it in the core of CMake.
It's 2x work to support CMake script and Lua indefinitely.
Actually, I don't agree with you here
Brandon Van Every wrote:
That's contradictory. You don't bog yourself down with enormous
support burdens for some teeny weeny percentage of people who do
something really weird. Software *is* invalidation of effort. Stuff
gets written, stuff gets changed, stuff gets maintained.
I don't
written computer language from one to another and have it work.
CMake script, by design, is a trivial language. If you actually do
implement Lua at some point, then I'll look at CMake -- Lua
translation, if it makes business sense for me to do so. I believe
other people in the Lua community
code like KDevelop. The translator would not help
them at all as the CMake code is embedded in C++ or java. There exist
cmake code generators. I guess you would say generate, then translate?
Sounds like a mess.
If CMake went to Lua, presumably these IDEs would want to do the same
things
will attempt it.
You've got a deal. I'll make sure to swing by Bill's office tomorrow
and remind him about his realization. Let me write that down. On a
post-it or something.
2 years break, that's a bargain Bill.
If CMake went to Lua, presumably these IDEs would want to do the same
things
a bargain Bill.
On that note, be sure to include actually implementing Lua.
If CMake went to Lua, presumably these IDEs would want to do the same
things in Lua.
That's indeed obvious, these IDEs would absolutely switch to LUA too.
Do they have a mailing list? My gut feeling is that they would
implementing Lua.
Again: *deal*.
February 29th, 2010 *precisely*.
Special CMake/Lua day, the 29th.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
.
2 years break, that's a bargain Bill.
On that note, be sure to include actually implementing Lua.
Again: *deal*.
February 29th, 2010 *precisely*.
Special CMake/Lua day, the 29th.
Or No Deal. 2 years is a number you've inappropriately reused from an
unrelated context. I'm
Sebastien BARRE wrote:
Again: *deal*.
February 29th, 2010 *precisely*.
Special CMake/Lua day, the 29th.
That will indeed be a very special day.
Shame really. I like Lua, and I find that the CMake script language
seems designed to make COBOL coders feel they don't actually
have the worst job
At 2/29/2008 12:39 AM, Brandon Van Every wrote:
Again: *deal*.
February 29th, 2010 *precisely*.
Special CMake/Lua day, the 29th.
Or No Deal. 2 years is a number you've inappropriately reused from an
unrelated context.
You are right, I apologize. Bill said:
we might have two
James Mansion wrote:
Ken Martin wrote:
other's variables out of the box. But with the Modules directory we either have to
have a copy of each module for every possible scripting language, on the fly
converters between any two scripting languages, or something like that to make it
work. Trying
If people want a tower of babel set of languages that can drive CMake,
they can do it now. Just write most of your build system in X, tell
your users they have to install CMake and X. Then use the powerful
language X to generate simple CMake files. (where X is python, tcl,
perl, lua, or what
that have many lines of CMake code in them. People have put a great
deal of effort into creating those files. If they don't have the time
to re-write in a new language, I don't blame them.
This is why I think an automated translation tool, say from CMake
script -- Lua, is essential to a migration
. There are very large projects
that have many lines of CMake code in them. People have put a great
deal of effort into creating those files. If they don't have the time
to re-write in a new language, I don't blame them.
This is why I think an automated translation tool, say from CMake
script -- Lua
On Wed, Feb 27, 2008 at 5:37 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
Brandon Van Every wrote:
I think if the automated translation tool had proven itself for a
couple of years, it would be perfectly reasonable to force people to
move on. So there is still that 2 year window of
Brandon Van Every wrote:
That's 2 cantankerous languages and a rather general problem domain.
CMake script is a rather limited language. Not that hard to map it to
Lua.
I don't know, I have heard about people using CMake for a general
purpose language :)
I don't think I have any
to make such people untangle their metaprogramming.
It would be much safer and easier to continue
to support it in the core of CMake.
It's 2x work to support CMake script and Lua indefinitely.
I just don't believe that
translation can work, and the fun part is that it can't even be proved
While the cmake language may not be beautiful, it works, and the users
(developers) are not supposed to write programs with it.
I do get your point that people should not *have* to program to do common
tasks. Some other build systems seem to rely on the user to do far too much.
The
In principle CMake implements two thing,
- a scripting language,
- and a make/build-file generator.
As I understand it, these two things are currently
mixed up in CMakeLib: all commands parse the arguments
(scripting functionality) and then call the generator
function with the
The other is that a non-trivial portion of CMake is written in the scripting
language ala the Modules directory. So supporting multiple languages becomes
problematic. Most languages are not designed to mix with other languages. I
doubt you can mix python and Lua and expect them to be able to
On Saturday 23 February 2008, Peter Kümmel wrote:
Hi Ken,
this is a reply to your email on the Lua list:
http://marc.info/?l=lua-lm=120275861422593w=2
It is nice to see that there is interest in Lua as
alternative scripting language. Since I've discovered
Lua I thought it would be a nice
Alexander Neundorf wrote:
On Saturday 23 February 2008, Peter Kümmel wrote:
Hi Ken,
this is a reply to your email on the Lua list:
http://marc.info/?l=lua-lm=120275861422593w=2
It is nice to see that there is interest in Lua as
alternative scripting language. Since I've discovered
Lua I
On Mon, Feb 25, 2008 at 2:06 PM, Alexander Neundorf
[EMAIL PROTECTED] wrote:
After having seen some presentations at FOSDEM, I'm even more convinced that
having only limited programming functionality available in build files is a
good thing.
What in particular confirmed this opinion of
Ken Martin wrote:
In VTK and ITK we did design a language independent toolkit and wrapped it
into Tcl, Python, Java etc so we have done that and have a good feel for it.
But for CMake I do not think it is a good idea for a couple reasons. One is
fragmentation of the community/support.
Every
On Monday 25 February 2008, Brandon Van Every wrote:
On Mon, Feb 25, 2008 at 2:06 PM, Alexander Neundorf
[EMAIL PROTECTED] wrote:
After having seen some presentations at FOSDEM, I'm even more convinced
that having only limited programming functionality available in build
files is a good
On Mon, Feb 25, 2008 at 2:22 PM, Peter Kümmel [EMAIL PROTECTED] wrote:
Then it is only possible to provide a C++ interface so that all the
module stuff works behind the scene (behind the interface), using one
scripting language only. And if a new module should go upstream it
must use this
Brandon Van Every wrote:
On Mon, Feb 25, 2008 at 2:22 PM, Peter Kümmel [EMAIL PROTECTED] wrote:
Then it is only possible to provide a C++ interface so that all the
module stuff works behind the scene (behind the interface), using one
scripting language only. And if a new module should go
Quoting Peter Kümmel [EMAIL PROTECTED]:
Ken Martin wrote:
In VTK and ITK we did design a language independent toolkit and wrapped it
into Tcl, Python, Java etc so we have done that and have a good feel for it.
But for CMake I do not think it is a good idea for a couple reasons. One is
Pau Garcia i Quiles wrote:
One Language to rule them all, One Language to find them, One Language
to bring them all and in the compiler bind them.
Nice, but wasn't the One destroyed? ;)
Peter
___
CMake mailing list
CMake@cmake.org
On Mon, Feb 25, 2008 at 3:14 PM, Peter Kümmel [EMAIL PROTECTED] wrote:
Pau Garcia i Quiles wrote:
One Language to rule them all, One Language to find them, One Language
to bring them all and in the compiler bind them.
Nice, but wasn't the One destroyed? ;)
Actually, all of the rings
I'm even more convinced that
having only limited programming functionality available in build files is
a
good thing.
While the cmake language may not be beautiful, it works, and the users
(developers) are not supposed to write programs with it.
OMG flame war Bring it! :)
Seriously
Brandon Van Every wrote:
Actually, all of the rings lost their power at that time.
Analogously, we'd forget about build systems and go into the West.
We could speculate about who's the Dark Lord. By my demeanor I am
surely an Uruk-hai captain. -)
Good closing words for this thread.
See you
I have testing CMake as my build system for medium sized proyects and i
view that change to a tiny scripting instead of CMake macros can be good.
For example in my project. i need stuff for compile other things that are
not out of the box supported by CMake, for example antltr files for generate
On Monday 25 February 2008, Ken Martin wrote:
...
OMG flame war Bring it! :)
How about: everybody should use Ruby, because all other languages suck ! ;-)
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Mon, Feb 25, 2008 at 5:14 PM, Alexander Neundorf
[EMAIL PROTECTED] wrote:
On Monday 25 February 2008, Ken Martin wrote:
...
OMG flame war Bring it! :)
How about: everybody should use Ruby, because all other languages suck ! ;-)
Ruby's license sucks. The price of Ruby's nice
can't organize options the way i want.
So would it be possible to make some hybrid kind of Cmake, which makes
it possible to slowly migrate.
Or how do you think about using existing modules in Cmake syntax. Maybe
calling Cmake macros from a Lua script?
How exactly did you wrap in Lua what
. CMake
script -- Lua translation is certainly doable, but someone would have
to do it, and it would be real work.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Ken Martin wrote:
other's variables out of the box. But with the Modules directory we either
have to have a copy of each module for every possible scripting language, on
the fly converters between any two scripting languages, or something like
that to make it work. Trying to figure out how to
On Tue, Feb 26, 2008 at 2:12 AM, James Mansion
[EMAIL PROTECTED] wrote:
Ken Martin wrote:
other's variables out of the box. But with the Modules directory we either
have to have a copy of each module for every possible scripting language,
on
the fly converters between any two scripting
I am not seeing the merit of trying to support multiple scripting
languages. This fragments CMake into many sub-language communities.
Who would handle all the inevitable bugs? It's many times the work of
maintaining a quality implementation with 1 scripting language.
I don't think this is
On Sun, Feb 24, 2008 at 8:03 AM, E. Wing [EMAIL PROTECTED] wrote:
Apple introduced
a second completely independent framework called Carbon, but they told
people they should use Cocoa to get first-class looking applications.
Kitware + the CMake community do not have the resources of Apple.
On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote:
On Sun, Feb 24, 2008 at 8:03 AM, E. Wing [EMAIL PROTECTED] wrote:
Apple introduced
a second completely independent framework called Carbon, but they told
people they should use Cocoa to get first-class looking applications.
Kitware +
On Sun, Feb 24, 2008 at 12:36 PM, E. Wing [EMAIL PROTECTED] wrote:
Again, you missed the point entirely. This isn't about Obj-C vs Lua or
any other languge. The point was that by providing a language bridge,
the whole language wars argument gets thrown out the window.
So are you going to
On Sun, Feb 24, 2008 at 12:56 PM, E. Wing [EMAIL PROTECTED] wrote:
On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote:
So are you going to write this framework for us, that makes all the
work of supporting multiple languages magically go away?
If you bothered actually reading my
as there will either be source
code showing how it's done, or somebody will bridge Lua.
-Eric
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Hi Ken,
this is a reply to your email on the Lua list:
http://marc.info/?l=lua-lm=120275861422593w=2
It is nice to see that there is interest in Lua as
alternative scripting language. Since I've discovered
Lua I thought it would be a nice drop-in for the
actual CMake macro language.
Here I
Hopefully other people will spend time debating the merits / demerits
of this, as people have gotten sick of hearing me talk about CMake and
Lua as of late. I'm happy that my irritance has caused people to
continue to discuss the possibilities, however. I will make one
point:
On Sat, Feb 23
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
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
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
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
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,
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
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,
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
- 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
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
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
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
));
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
, 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
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
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
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
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
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
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.
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
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
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
)
(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 little different. If CMake adopts Lua, then it should be
embedded with CMake (especially since
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
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:
1 - 100 of 108 matches
Mail list logo
