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 l
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, 2
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)
> foobazify(${Element})
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):
f
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 m
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 'I
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 in
On 01/14/2016 09:11 AM, Charles Huet wrote:
> Thanks for the insight !
[snip]
> but Lua seems to be a better fit for CMake now that I think about the
> constraints you listed.
Yes, Eric, thanks for the excellent post summarizing the history of this
issue and why Lua is a great candidate.
> The ma
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 provided
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 hea
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 13:14 +, Charles H
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 Neun
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. Then developers wo
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, t
I fully agree with Alexander.
It seems a very bad idea to use a general purpose script language to manage
CMake stuff.
For sure, CMake language is a bit “curious” :) and changing for a more user
friendly one is a good idea but, in my opinion, only dedicated languages (I.e.
Specialised for the p
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 ,
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 l
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 à
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 , ant at
the end the CMAKE description is longer than the one I built dire
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 sp
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
http://thread.gmane.org/gmane.comp.programming.tools
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 CMake
> language
> in a c
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 we
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
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
25 matches
Mail list logo