Re: [cmake-developers] CMake alternative language

2016-01-29 Thread Eric Wing
Just to answer some of your questions on this... > > I think the first step is design brainstorming and discussion to see if > we can find something acceptable. > > IIRC one problem with earlier attempts at introducing Lua was that CMake's > dynamic scoping is difficult to reconcile with Lua's

Re: [cmake-developers] CMake alternative language

2016-01-15 Thread Jean-Michaël Celerier
Throw in a > list(GET MyList ${i} ElementA) > list(GET MyOtherListOfSameSizeThanMyList ${i} ElementB) > foobazify(${ElementA} ${ElementB}) (I did not want to put a ginormous code snippet, just to outline the amount of code necessary to do simple things) On Fri, Jan 15,

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread Charles Huet
I think this problem already exists. When "projects build elaborate macro/function systems in the CMake language", you have to understand the build system program. And in my experience, those systems are widely different from one another. I have seen a system where you defined lots of variables,

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread Jean-Michaël Celerier
On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf wrote: > > My personal opinion: if the full power of python would be available, the > build > scripts would quickly turn into real programs, because programmers would be > tempted to do so if all of python would be available.

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread Charles Huet
As long as CMake embeds everything that is required, I don't see the additional pain (since this is what it already does with the CMake language). Le jeu. 14 janv. 2016 à 13:35, Jean-Michaël Celerier < jeanmichael.celer...@gmail.com> a écrit : > > On Wed, Jan 13, 2016 at 10:21 PM, Alexander

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread Eric Wing
I am hesitant to add more fuel to the fire for this discussion because it has been discussed many times before through the years and my sense is that this isn’t what Brad is really interested in pursuing. I encourage you search the mailing list history. I’ll try to summarize (off the top of my

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread yann suisini
Maybe just implement the python syntax (or a t lease a subset) in the cmake core , so no need extern dep and provide a clean/defined interface to be able to call complex external script is whatever languages. 2016-01-13 14:27 GMT+01:00 Saša Janiška : > On Sri, 2016-01-13 at

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread Charles Huet
Thanks for the insight ! I started going towards python because I am more familiar with it, but Lua seems to be a better fit for CMake now that I think about the constraints you listed. The main point I am getting from your mail is that Kitware may not want to go down this route, even if

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread Jean-Michaël Celerier
The problem is doing : list(LENGTH MyList NumList) math(EXPR MaxItList ${NumList}-1) foreach(i RANGE ${MaxItList}) list(GET MyOtherListOfSameSizeThanMyList ${i} Element) foobazify(${Element}) endforeach() instead of : for i in range(0, MyList.size):

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread J Decker
On Thu, Jan 14, 2016 at 3:09 PM, Jean-Michaël Celerier wrote: > The problem is doing : > > list(LENGTH MyList NumList) > math(EXPR MaxItList ${NumList}-1) > > foreach(i RANGE ${MaxItList}) > list(GET MyOtherListOfSameSizeThanMyList ${i} Element)

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread Stephen Kelly
Charles Huet wrote: > When the configure step takes > about 30 seconds, and all you can do is use MESSAGE() to find what > happens, this is no walk in the park. A real debugger would do a world of > good to CMake. This is one of the things that I address with the daemon work - a 'recording' is

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread Tamás Kenéz
Looking at what kind of mistakes the newcomers make, I think it's rather the global workflow and the roles of certain key variables/properties they don't get. At first their problem is not that they can't make a for-loop or increment a variable. It's that they don't understand how the build and

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread J Decker
My stumbling blocks are the use of keywords instead of operators... if( Something == ${SomeOtherThing} ) vs if( Something STREQUAL ${SomeOtherTHing} ) It might be nice if the operator '=' could be used in addition to the function SET() SET( a something ) becomes A = something Was gong to say

Re: [cmake-developers] CMake alternative language

2016-01-13 Thread Charles Huet
Hi, > * There is a lot of code out there in the current CMake language so I do not think it is realistic to drop it. I'm not proposing that this change. I am. (more below) > * Many projects build elaborate macro/function systems in the CMake language in order to end up with a declarative

Re: [cmake-developers] CMake alternative language

2016-01-13 Thread Charles Huet
I don't think this is a dumb question, actually this is part of the problem I think would be resolved whit a new language. The barrier of entry to using CMake is too high in my opinion, and I think using an existing language would lower it *a lot*. Thanks for sharing :) Le mer. 13 janv. 2016 à

Re: [cmake-developers] CMake alternative language

2016-01-13 Thread Saša Janiška
On Sri, 2016-01-13 at 13:14 +, Charles Huet wrote: > I don't think this is a dumb question, actually this is part of the > problem I think would be resolved whit a new language. > > The barrier of entry to using CMake is too high in my opinion, and I > think using an existing language would

Re: [cmake-developers] CMake alternative language

2016-01-13 Thread Alexander Neundorf
On Wednesday, January 13, 2016 10:59:39 yann suisini wrote: > Hi, > > I'm a new user of CMake, but I just want to express my newcomer point of > view. > Honestly , I can feel the power of CMAKE, but it's a real pain to learn ... > I'm using CMAKE for an embedded platform with a non GNU compiler ,

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

2016-01-11 Thread Petr Kmoch
Hi all. I'd like to voice my opinion as a somewhat advanced CMake user here. For me, one of the strongest points of CMake is the fact that its project specification is procedural rather than declarative. In my current job, for example, we have a significant framework built in CMake which handles

Re: [cmake-developers] CMake alternative language

2016-01-11 Thread Brad King
Hi Folks, I'm replying directly to my previous post in this thread in order to consolidate responses to related discussion raised in others' responses to it: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

2016-01-11 Thread Charles Huet
Hi, > * The cmState infrastructure builds on a "snapshot" design with a goal of being able to "fork" configuration/generation temporarily and then revert back, and to be able to re-start configuration from the middle. These goals may be incompatible with any language whose implementation

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

2016-01-11 Thread Pau Garcia i Quiles
On Fri, Jan 8, 2016 at 5:30 PM, Brad King wrote: > See above. Lua has come up several times in the past in particular because > its implementation is meant to be small and embeddable. I've thought a few > times about how to make Lua scripting available from within the

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

2016-01-08 Thread Brad King
Hi Charles, Thanks for your efforts in exploring this topic. CMake's current language grew incrementally out of something that was not originally intended as a programming language. The cmState refactoring Stephen Kelly has started is a huge step toward enabling alternative languages, but there