Brandon Van Every wrote:
1) licenses that are unfriendly to unfettered commercial development,
often don't get accepted by commercial developers.
Not really.
cmake is a stand-alone utility. With any of the scripting language
licenses, you can still ship cmake with your own, say,
On Nov 8, 2007 12:10 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:
Anyway... why are you guys so concerned about cmake's license? To me,
as long as the code is open source and forkable, that's all I care for
cmake. I'm not planning to make money selling a fork of cmake, borrow
its source
Gonzalo Garramuño wrote:
3) Your license choices are fine for your own use, but you'd need to
talk to Kitware about what they actually want.
Now, that could be a fair point. If I was interested in having Kitware
distribute cmake with ruby. Which albeit I like the idea, I don't think
I
On 11/8/07, Bill Hoffman [EMAIL PROTECTED] wrote:
Gonzalo Garramuño wrote:
[...] Also, I am
not sure having N languages for CMake would be the best approach. So,
you go to build a project, and hey they are using CMake, cool, I know
how to run CMake, oh wait, that one is ruby CMake, I
On Thursday 08 November 2007, Mike Jackson wrote:
...
As a user of CMake let me second this notion also. CMake only depends
on a C++ compiler which is every where. Tying CMake to Ruby, Perl, tk
or anything else may actually decrease CMake's market penetration. I
don't really see Ruby running
On Nov 8, 2007 7:01 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:
If cmake was a popular C library on the other hand... the type of OSI
licensing would indeed matter *much* more.
What if I just want to rip a chunk of code out of Ruby and reuse it
somewhere? I'll have the PITA of carrying the
Juan Sanchez wrote:
I was reading exactly the link you sent, and the same one you accused
Brandon of not reading. If there were supplemental materials, you
should have sent them. I am not a lawyer.
To Juan:
Yes. The best place for any license question about source code is, as
usual, the
I was reading exactly the link you sent, and the same one you accused
Brandon of not reading. If there were supplemental materials, you
should have sent them. I am not a lawyer.
To be honest, the only compelling languages I've seen so far in this
discussion is lua and tcl. This is because they
Sanchez, Juan wrote:
This part of the license would concern me. Are all files of interest,
by other authors, guaranteed to be BSD friendly?
Again, read LEGAL. You will then find that:
regex when used with Ruby it is Ruby licensed, based on Onigurama.
utils is BSD, credit going to Lucent
For interest, this topic has been brought up before.
http://public.kitware.com/pipermail/cmake-promote/2005-December/39.html
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Nov 7, 2007 8:55 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:
Sanchez, Juan wrote:
This part of the license would concern me. Are all files of interest,
by other authors, guaranteed to be BSD friendly?
Other files may use Perl's Artistic License.
That's the license I had read, that
Ken Martin wrote:
I have looked at incorporating Lua into CMake as an alternate language.
Interesting. You didn't by any chance used swig to wrap it?
I admit I would be curious to see that fork of cmake to study the changes.
Using swig right now would be the best approach, as with just a
. I would think BSD type licensing
and compactness would be more important.
Juan
-Original Message-
From: [EMAIL PROTECTED] on behalf of Gonzalo Garramuño
Sent: Mon 11/5/2007 4:55 PM
To: Ken Martin; CMake ML; Sanchez, Juan
Subject: Re: [CMake] improve the CMake language?
Ken Martin
Brandon Van Every wrote:
I didn't realize that Ruby is GPLed. http://www.ruby-lang.org/en/LICENSE.txt
Oh well, so much for embedding Ruby!
It isn't. Where did you get that idea from !? Brandon, you have a
tendency to email FUD that is amazing... even when you provide links to
text that
On Nov 5, 2007 5:30 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:
Brandon Van Every wrote:
I didn't realize that Ruby is GPLed.
http://www.ruby-lang.org/en/LICENSE.txt
Oh well, so much for embedding Ruby!
It isn't. Where did you get that idea from !? Brandon, you have a
tendency
From: Eric Noulard [EMAIL PROTECTED]:
I used Java for 4+ years (all thoses years are overlapping :=)
it was really pleased using it for cross platform GUI.
And I was really disappointed because the java I used
was lacking generics such that I need to cast here and there when
using
Eric Noulard wrote:
CMAKE_LOAD_PLUGIN(TCL)
CMAKE_TCL(IN_VAR a
IN_VAR b
OUT_VAR g
OUT_VAR h
SCRIPT_STRING any tcl code)
or
CMAKE_TCL(IN_VAR a
IN_VAR b
OUT_VAR g
On Fri, 2 Nov 2007, Brandon Van Every wrote:
On Nov 1, 2007 11:40 PM, Sanchez, Juan [EMAIL PROTECTED] wrote:
Tcl is a simple language, and is well understood. It has already been
ported to about every platform out there. You don't need QT or wxWidgets,
because the Tk extensions of it
Sanchez, Juan wrote:
Hello Bill,
add_library(foo SHARED foo.cxx)
won't work.
I meant it worked in the current cmake language, I know it does not work
in tcl.
Developers who are not hostile to ideas concerning improvements to the
language.
I am not hostile to ideas about improvements
On Nov 2, 2007 6:04 AM, Eric Noulard [EMAIL PROTECTED] wrote:
Many features in the CMake language don't really work the way people
expect, or are not documented, or both.
Documentation is not as good as it should be
but re-implementing something (either TCL, Python, Perl)
won't make the
On Nov 2, 2007 9:04 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:
Brandon Van Every wrote:
My concern is that if the status quo is maintained, CMake script will
always be ugly to program with.
Yes. No doubt about that. It is already uglier to program with than
most modern scripting
Existing CMake plugin :
EXECUTE_PROCESS(COMMAND tclsh $ENV{HOME}/myTclScript.tcl OUTPUT_VARIABLE
ov RESULT_VARIABLE rv)
You are responsible for making sure tclsh is callable for your project's
users...
Similarly for python, ruby, perl, shell script, or *whatever*
Or, if you want it done as part
2007/11/2, David Cole [EMAIL PROTECTED]:
Existing CMake plugin :
EXECUTE_PROCESS(COMMAND tclsh $ENV{HOME}/myTclScript.tcl OUTPUT_VARIABLE
ov RESULT_VARIABLE rv)
Yes you are right I can do that.
You are responsible for making sure tclsh is callable for your project's
users...
That why I
On Nov 2, 2007 11:49 AM, Juan E. Sanchez [EMAIL PROTECTED] wrote:
On Fri, 2 Nov 2007, Brandon Van Every wrote:
To make real improvements in all of those areas, you'd need a lot of
funding. What kind of mandate do you have? There's not much point in
saying everything's gonna be better if
Brandon Van Every wrote:
On Nov 2, 2007 11:49 AM, Juan E. Sanchez [EMAIL PROTECTED] wrote:
On Fri, 2 Nov 2007, Brandon Van Every wrote:
To make real improvements in all of those areas, you'd need a lot of
funding. What kind of mandate do you have? There's not much point in
saying
Brandon Van Every wrote:
Is it worth trying to address these problems and make CMake a better
scripting language?
Yes, but currently as a low priority. CMake first needs to have an
extremely solid cross-compile toolchain and support as many systems as
possible first without any major
Hi all,
I'm interested in the idea of a more powerful CMake scripting.
I'm convinced I lack powerful scripting sometimes (may be many times)
but my opinion is it's not CMake's script job.
2007/11/2, Sanchez, Juan [EMAIL PROTECTED]:
Tcl is a simple language, and is well understood. It has
On Nov 2, 2007 1:01 PM, Juan Sanchez [EMAIL PROTECTED] wrote:
Brandon Van Every wrote:
On Nov 2, 2007 11:49 AM, Juan E. Sanchez [EMAIL PROTECTED] wrote:
On Fri, 2 Nov 2007, Brandon Van Every wrote:
To make real improvements in all of those areas, you'd need a lot of
funding. What kind
Brandon Van Every wrote:
My concern is that if the status quo is maintained, CMake script will
always be ugly to program with. This will put it at a disadvantage
compared to build systems written in Python, Ruby, or Perl. I'm not
just talking about SCons and so forth. I'm talking about a
,
Juan
-Original Message-
From: [EMAIL PROTECTED] on behalf of Bill Hoffman
Sent: Thu 11/1/2007 8:03 PM
To: Brandon Van Every
Cc: cmake@cmake.org
Subject: Re: [CMake] improve the CMake language?
Brandon Van Every wrote:
My concern is that if the status quo is maintained, CMake script
Sanchez, Juan wrote:
Tcl is a nice language for implementing declarative commands. It can be
easily built on about every platform out there, and the language rules
are well known. It is small, and very easy to compile a standalone Tcl
based interpreter with the CMake commands built in. The
Sanchez, Juan wrote:
Tcl is a nice language for implementing declarative commands. It can be
easily built on about every platform out there, and the language rules
are well known. It is small, and very easy to compile a standalone Tcl
based interpreter with the CMake commands built in. The
-Original Message-
From: Bill Hoffman [mailto:[EMAIL PROTECTED]
Sent: Thu 11/1/2007 9:18 PM
To: Sanchez, Juan
Cc: Bill Hoffman; Brandon Van Every; cmake@cmake.org
Subject: Re: [CMake] improve the CMake language?
Sanchez, Juan wrote:
Tcl is a nice language for implementing declarative
33 matches
Mail list logo
