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, 200
> 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 Appl
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.
>
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
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 r
On 2/24/08, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> 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 multi
> 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 wit
> 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 t
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-l&m=120275861422593&w=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
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-l&m=120275861422593&w=2
It is nice to see that there is interest in Lua as
alternative scripting language. Since I've discovered
Lua I thou
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 o
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 ti
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
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
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
fragmen
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
http://www.cmake.or
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 r
> 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! :)
Seriousl
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 n
Ken Martin wrote:
Which is why CMake has
include, macro, foreach etc. which are all staples of a programming
language.
Right, much better to spend time on something else, and use Lua for all
these things.
Add wxLua , and the graphical interface becomes easy too. CMakeSetup is
nice, but i ca
On Mon, Feb 25, 2008 at 5:15 PM, klaas.holwerda <[EMAIL PROTECTED]> wrote:
> Ken Martin wrote:
> > Which is why CMake has
> > include, macro, foreach etc. which are all staples of a programming
> > language.
> >
> Right, much better to spend time on something else, and use Lua for all
> these
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 man
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
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 buil
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
On Wed, Feb 27, 2008 at 4:34 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
>
> Also, backwards compatibility is something we take very seriously. If
> someone picks CMake as a build tool, we have to respect that choice and
> try our best not to break that project. There are very large projects
>
Brandon Van Every wrote:
On Wed, Feb 27, 2008 at 4:34 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
Also, backwards compatibility is something we take very seriously. If
someone picks CMake as a build tool, we have to respect that choice and
try our best not to break that project. There are ve
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 wi
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 idea
On Wed, Feb 27, 2008 at 8:58 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> 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
Brandon Van Every wrote:
Only thing problematic I could see, is if someone's getting clever and
using CMake script to generate CMake script. I think it would be
reasonable to make such people untangle their metaprogramming.
That's crazy, no one would do something like that... But even if the
On Thu, Feb 28, 2008 at 9:53 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> >
> > Only thing problematic I could see, is if someone's getting clever and
> > using CMake script to generate CMake script. I think it would be
> > reasonable to make such people untangle
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 thi
On Thu, Feb 28, 2008 at 4:08 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> I think it is an enormous effort to write a translator. I think
> translators don't work. It is one thing to convert a word document from
> one version to another. It is a totally different thing to translate a
> hum
Brandon Van Every wrote:
Just suppose I am correct and it is
not possible to write a good enough translator. Would you then still
advocate dropping the cmake language?
Of course not. That's why I said the translator would have to prove
itself for 2 years.
So, I guess I will wait until t
On Thu, Feb 28, 2008 at 5:54 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> >
> >> Just suppose I am correct and it is
> >> not possible to write a good enough translator. Would you then still
> >> advocate dropping the cmake language?
> >
> > Of course not. T
At 2/28/2008 09:06 PM, Brandon Van Every wrote:
> So, I guess I will wait until then, and you can prove me wrong... Until
> then, can you give it a break?
Sure. Long as you realize that not everybody shares your pessimism
about translators, and that if you do implement Lua support, people
w
On Thu, Feb 28, 2008 at 11:41 PM, Sebastien BARRE
<[EMAIL PROTECTED]> wrote:
> At 2/28/2008 09:06 PM, Brandon Van Every wrote:
>
> > > So, I guess I will wait until then, and you can prove me wrong... Until
> > > then, can you give it a break?
> >
> >Sure. Long as you realize that not every
At 2/29/2008 12:03 AM, Brandon Van Every wrote:
> 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.
On that note, be sure to include ac
On Fri, Feb 29, 2008 at 12:11 AM, Sebastien BARRE
<[EMAIL PROTECTED]> wrote:
> At 2/29/2008 12:03 AM, Brandon Van Every wrote:
>
> > > 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
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 in
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:
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
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 that
On Sat, Mar 1, 2008 at 7:08 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> Especially in open source, I think it is
> reasonable to make developers do trivial amounts of work to move on,
> at some point, if the migration tools have been thoroughly tested and
> proven in the field.
I di
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 translat
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.
Bil
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 g
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 aim
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*.c
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
On Sunday 02 March 2008, Timothy M. Shead wrote:
> On Sat, 2008-03-01 at 15:20 -0500, Brandon Van Every wrote:
> > > * no well defined syntax:
> > >
> > > - missing datatypes; all seems to be a string. Mastering ';' and
> > > spaces is trial-and-error game :(
> >
> > Totally agree on this p
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 langu
61 matches
Mail list logo
