Re: [cmake-developers] CMake alternative language

[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 lexical scoping.  Lua
> cannot be given direct access to CMake variable scopes because Lua data
> structures may outlive the CMake dynamic scopes, leading to dangling
> references.

I don't have a good solution for this. I think the original CMake/Lua
bridge was basically a 1-to-1 API mapping with the CMake API. So the
idea was anything you do in native Lua lives in your Lua state
following the standard Lua lifecycles of things, but communicating
with CMake required going through the CMake public API (via
functions/macros via Lua bindings to the API). For global variables, I
think there was a special Lua table for CMake globals which had a
metamethod which did something similar to set the CMake values.

Thus, I can't remember if there were any dangling data structures. I
think about ADD_LIBRARY or ADD_EXECUTABLE which essentially returns a
TARGET object which has a lifecycle. When returned to Lua, we wrap it
in a userdata. The wrapper could lose its scope and the wrapper could
get garbage collected. But the backend doesn't need to actually
collect or destroy the object so CMake can still manage the resource
itself.

An aside though, I do find the scoping and lifetime rules of CMake
very difficult to work with. I feel like I still don't have a good
intuition or understanding of when many things happen in CMake. Since
we use CMake to compile C/C++/etc which are lexical scoping, I find
this to be challenging, especially since I don't really want to be
focusing on details like this when I'm just trying to get my program
compiled. So figuring out how to better embrace (Lua's) lexical
scoping moving forward might be a win.


> I'd also prefer an approach that allows us to offer newer versions of Lua
> as they come out while still processing old scripts unchanged.  This means
> that all Lua code must lie in a context where CMake knows the version of
> Lua for which it was written.  I'd like to retain the possibility of
> supporting multiple Lua versions to allow future such version transitions.
> (Implementation symbols can be mangled to support multiple versions linked
> in one program.)

This should be possible, though it's not a topic I've carefully
followed myself. I think simply mangling all the API functions
differently should prevent any conflicts. (I don't think Lua has any
global/static shared state internally which avoids those problems.)

I should also point out though that if you are going to support
multiple simultaneous versions of Lua, things could get messy if the
user needs Lua state preserved across multiple calls (i.e. not a
purely functional design). So what happens if the user starts in Lua
5.3 and creates some data, but then calls a script that only works in
Lua 5.1. The VMs can't be mixed.


>
>   cmake_lua( [LOCAL ...] CODE ...)
>
> The  must be "5.2", the Lua language version.

One thing to keep in mind is that for at least Lua 5, most of the
scripting side changes have been pretty minor. Most of the time,
script authors figure out how to write a script that runs across all
versions of Lua 5. So specifying a list of supported versions may be
desirable.




>   number: value is interpreted as a decimal representation of
>   a floating point value to be stored in a Lua number.

One interesting introduction to Lua 5.3 (already out) is integer
subtypes in Lua, so it now has separate float and integer types if
useful.


>
> set(deg 90)
> cmake_lua(5.2 LOCAL number{deg} CODE [[
>   return { sin = math.sin(deg*math.pi) }]])
> message("sin(${deg}') = ${sin}')
>

So I personally imagined writing much bigger chunks in Lua directly
and directly invoking CMake APIs (via bindings, sort of like the
prototype). Not that I disagree with anything here. But I think for my
use case, the time I need Lua the most is for complicated code that is
really unwieldily in the native CMake language, not for little things.

For example, one of the worst parts of CMake code I have right now in
my current project is I need to track all the resource files
(separated into types like images, scripts, dynamic libraries,
plugins) in my project and retain the relative directory hierarchy for
everything so I can reconstruct them in the application
packaging/bundling process (a custom step I have as part of the build)
preserving the layout (but with platform aware adjustments as needed).
Basically, I wanted multi-dimensioned tables, but I don't get those in
CMake, so I'm doing really painful things with global strings and
appending key names to strings to make new unique string lists. It is
a beast of a system right now because so many things have to use it
and the key names are often done with variables there are a lot of

Re: [cmake-developers] CMake alternative language

[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, 2016 at 1:28 AM, J Decker  wrote:

> 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})
> > endforeach()
> >
> Probably a bad exmple, since you're not using MyList or i that simplifies
> to
>
> foreach( Element ${MyOtherListOfSameSizeThanMylist} )
> foobazify( ${Element} )
> endforeach()
>
> > instead of :
> >
> > for i in range(0, MyList.size):
> > foobazifiy(MyOtherListOfSameSizeThanMyList[i])
> >
> >
> >
> >
> >
> > On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet 
> > wrote:
> >>
> >> 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
> >>  a écrit :
> >>>
> >>>
> >>> 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
>  would
>  have to understand two programs: the program itself, and the "build
>  program".
> >>>
> >>>
> >>> The problem is when you have to do a real program for your build system
> >>> anyways (which occurs one day or another for any large enough project I
> >>> guess).
> >>> Currently it's a real pain (but it'd be even more painful to have to
> ship
> >>> Python / Bash / $script_language as part of your build system).
> >>> --
> >>>
> >>> Powered by www.kitware.com
> >>>
> >>> Please keep messages on-topic and check the CMake FAQ at:
> >>> http://www.cmake.org/Wiki/CMake_FAQ
> >>>
> >>> Kitware offers various services to support the CMake community. For
> more
> >>> information on each offering, please visit:
> >>>
> >>> CMake Support: http://cmake.org/cmake/help/support.html
> >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >>> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>>
> >>> Visit other Kitware open-source projects at
> >>> http://www.kitware.com/opensource/opensource.html
> >>>
> >>> Follow this link to subscribe/unsubscribe:
> >>> http://public.kitware.com/mailman/listinfo/cmake-developers
> >
> >
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[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, then just
imported a file which used those to perform the add_library and such in the
X-Macro pattern (
https://en.wikibooks.org/wiki/C_Programming/Preprocessor#X-Macros).

I think having a language that allows for more terse expressions would be a
net gain.


Also, I find ironic to preach for a simple language when CMake is mainly
targetted at C++.
C++ programmers are used to having *lots* of very powerful tools at their
disposal (template meta-programming, operator overloading, macros, etc) and
having to choose which one to use for the job.

If you do not trust your team mates to keep the buildsystem simple and to
the point even if they had lots of stuff at their disposal, how can you
trust them with the C++ program ?


Le jeu. 14 janv. 2016 à 09:04, CHEVRIER, Marc  a
écrit :

> 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 problem to solve) must be considered.
>
> May be a good approach is to enhance current language for more flexibility
> (for example adding capability for functions to return value, etc…)
>
> Marc
>
>
>
>
>
> On 13/01/16 22:21, "cmake-developers on behalf of Alexander Neundorf" <
> cmake-developers-boun...@cmake.org on behalf of neund...@kde.org> wrote:
>
> >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 , ant
> at
> >> the end the CMAKE description is longer than the one I built directly in
> >> Ninja.
> >> I had to write a python script to parse my eclipse project xml to
> create a
> >> list of sources files usable by CMAKE.
> >> The first thing I thought was: why this is not a part of cmake ? And the
> >> second thing was : why not using the scripting power of an existing
> >> language like Python(or other one) and add CMAKE as a framework /
> library ?
> >
> >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
> would
> >have to understand two programs: the program itself, and the "build
> program".
> >
> >I'm not saying that the cmake language is beautiful, but it helps to keep
> >cmake scripts somewhat simple, and not evolve into a second program
> >additionally to the actual program which is being built.
> >
> >Alex
> >
> >--
> >
> >Powered by www.kitware.com
> >
> >Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> >Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> >CMake Support: http://cmake.org/cmake/help/support.html
> >CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> >Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> >Follow this link to subscribe/unsubscribe:
> >http://public.kitware.com/mailman/listinfo/cmake-developers
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow 

Re: [cmake-developers] CMake alternative language

[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. Then developers would
> have to understand two programs: the program itself, and the "build
> program".


The problem is when you have to do a real program for your build system
anyways (which occurs one day or another for any large enough project I
guess).
Currently it's a real pain (but it'd be even more painful to have to ship
Python / Bash / $script_language as part of your build system).
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[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 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
>> would
>> have to understand two programs: the program itself, and the "build
>> program".
>
>
> The problem is when you have to do a real program for your build system
> anyways (which occurs one day or another for any large enough project I
> guess).
> Currently it's a real pain (but it'd be even more painful to have to ship
> Python / Bash / $script_language as part of your build system).
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[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 head) about why Lua (as
opposed to other languages).

- Lua above all other languages was recommended by me and others
because it satisfied all the constraints:
- It is tiny and can be included with the CMake source and doesn’t
impact the size of CMake in any significant way
- Being 100% ANSI C allows it to go everywhere CMake already goes and
satisfies the requirement that only a C++ compiler is needed to
bootstrap it.
- Lua is a language designed to be embedded, for this very kind of 
purpose.
- Lua is sandboxed by default and has a minimal (and optional)
standard library.
- This means users won’t be encouraged to call all sorts of
non-portable library calls like with some other languages. CMake can
control what APIs are exposed addressing those concerns that a full
programming language may allow too much variance and craziness in the
community.
- Lua’s liberal license is compatible with CMake’s liberal license.

- Lua is one of the cleanest, simplest mainstream languages out there
and is incredibly easy to learn, yet still supporting a wide range of
higher-level constructs (functions as first class values, closures,
proper tail recursion). Documentation and tutorials are readily
available.
- Lua’s core data structure is the table, which is a extremely similar
to JSON (which it happens to also predate), which makes lists and
declarative data style very easy and natural to do.
- Lua has proven itself in the video game industry in that C/C++
developers are comfortable dealing with it (not a syntax shell shock
to them, say like LISP, or quite frankly CMake)
- Lua being a full, well designed programming language allows for ways
to write things which is currently really hard in CMake’s language.
Additionally, adding features to CMake’s language is hard in that you
have to think about all the potential side-effects, edge cases, and
inconsistencies. Lua takes this burden away and how to use everything
is well known/documented.

- To prove to us that CMake was already too far down the road and
retrofitting Lua into CMake was not practical, Dr. Ken Martin had a
CMake/Lua proof of concept working in like 13 hours. (Oops.)
- But it was decided that Kitware didn’t want to go down this road.

- We attempted to build off Ken Martin’s experiment to keep it alive,
but that project essentially failed.
- Lack of time, resources, expertise, etc, and this was back in the
CVS days so keeping up with the mainline was hell since merge tracking
is pretty much non-existent.
- There was one interesting thing implemented showing that both
existing CMake script and Lua script could co-exist. And I think there
was even a proof a concept that different language scripts could call
one another.



So just on the constraints/requirements issue, I think we convinced
Brad, that *if* anything should be chosen, it should be Lua, which is
why Lua is still in his head. And these constraints are still in play.
I am constantly fighting dependency hell on platforms. It is nice that
CMake has no external dependencies except a C++ compiler and can
bootstrap itself. I recently did a bunch of work on a Raspberry Pi and
I needed to build CMake; no problem. I just tried to build Swift on
the Pi. I got hit by a bug where the build process pulls in the wrong
version of Python (2 vs 3) if both exist on the system. What a mess.
(And a 9+ hour build cycle to retry.) Not to mention the disk space
problem of needing all these dependencies.

But it sounds like Brad is more interesting in a purely declarative
replacement for CMake.
That would be nice for all the editor-assist reasons. Though I’m also
skeptical of pulling that off (though I hope it can be done in a
useful way). There are other systems like that, yet, I’m using CMake
for a reason. I don’t have any real insight on the problem, but I
recall hacking Ant XML files and just to have a simple conditional
(if/else) was a huge PITA. And as these things cascade with more
conditionals, it becomes a major effort. Antidotally, I watched
several projects try to use Gyp even though there was a CMake
description already written (albeit, not working for the platforms we
needed). I watched from the sidelines as those projects failed to get
Gyp working. I don’t have any insight in why unfortunately. For one
project though, I did later come in and did get the CMake description
working.

I try really hard to keep my CMake really simple. But unfortunately,
it always gets complicated. Just the fact that platforms and
environments are so different always impacts my CMake scripts. But I’m
very glad that CMake seems to get the job done. Lua would help 

Re: [cmake-developers] CMake alternative language

[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 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 lower it *a lot*.
>
> Personally I'm determinant to use CMake, mostly due to its maturity and
> CPack's features, but recently stumbled upon Meson http://mesonbuild.com/
> )
> build system whose goal is "to be both extremely fast, and, even more
> importantly, as user friendly as possible."...it also uses Ninja instead
> of Make as backend.
>
> Otoh, I believe that main problem with CMake is lack of quality docs -
> even
> Mastering CMake book has constantly very bad reviews.
>
> Sincerely,
> Gour
>
>
> --
> One who sees inaction in action, and action in inaction,
> is intelligent among men, and he is in the transcendental position,
> although engaged in all sorts of activities.
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[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 provided with a working prototype, with the
ability of slow migration by using both CMake script and Lua.

I understand that some users are against such a change (as pointed out in
this very thread) but I'd be willing to contribute time and effort towards
it, if given the assurance it would not be in vain.

>I try really hard to keep my CMake really simple. But unfortunately,
it always gets complicated. Just the fact that platforms and
environments are so different always impacts my CMake scripts. But I’m
very glad that CMake seems to get the job done. Lua would help me
avoid fighting the CMake language, and that would be very welcome. But
I don’t expect the messiness to ever truly go away…that is the
byproduct of systems/environments being so different and ever
changing.

This perfectly sums up what I feel :)

Le jeu. 14 janv. 2016 à 14:46, Eric Wing  a écrit :

> 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 head) about why Lua (as
> opposed to other languages).
>
> - Lua above all other languages was recommended by me and others
> because it satisfied all the constraints:
> - It is tiny and can be included with the CMake source and doesn’t
> impact the size of CMake in any significant way
> - Being 100% ANSI C allows it to go everywhere CMake already goes
> and
> satisfies the requirement that only a C++ compiler is needed to
> bootstrap it.
> - Lua is a language designed to be embedded, for this very kind of
> purpose.
> - Lua is sandboxed by default and has a minimal (and optional)
> standard library.
> - This means users won’t be encouraged to call all sorts of
> non-portable library calls like with some other languages. CMake can
> control what APIs are exposed addressing those concerns that a full
> programming language may allow too much variance and craziness in the
> community.
> - Lua’s liberal license is compatible with CMake’s liberal license.
>
> - Lua is one of the cleanest, simplest mainstream languages out there
> and is incredibly easy to learn, yet still supporting a wide range of
> higher-level constructs (functions as first class values, closures,
> proper tail recursion). Documentation and tutorials are readily
> available.
> - Lua’s core data structure is the table, which is a extremely similar
> to JSON (which it happens to also predate), which makes lists and
> declarative data style very easy and natural to do.
> - Lua has proven itself in the video game industry in that C/C++
> developers are comfortable dealing with it (not a syntax shell shock
> to them, say like LISP, or quite frankly CMake)
> - Lua being a full, well designed programming language allows for ways
> to write things which is currently really hard in CMake’s language.
> Additionally, adding features to CMake’s language is hard in that you
> have to think about all the potential side-effects, edge cases, and
> inconsistencies. Lua takes this burden away and how to use everything
> is well known/documented.
>
> - To prove to us that CMake was already too far down the road and
> retrofitting Lua into CMake was not practical, Dr. Ken Martin had a
> CMake/Lua proof of concept working in like 13 hours. (Oops.)
> - But it was decided that Kitware didn’t want to go down this road.
>
> - We attempted to build off Ken Martin’s experiment to keep it alive,
> but that project essentially failed.
> - Lack of time, resources, expertise, etc, and this was back in the
> CVS days so keeping up with the mainline was hell since merge tracking
> is pretty much non-existent.
> - There was one interesting thing implemented showing that both
> existing CMake script and Lua script could co-exist. And I think there
> was even a proof a concept that different language scripts could call
> one another.
>
>
>
> So just on the constraints/requirements issue, I think we convinced
> Brad, that *if* anything should be chosen, it should be Lua, which is
> why Lua is still in his head. And these constraints are still in play.
> I am constantly fighting dependency hell on platforms. It is nice that
> CMake has no external dependencies except a C++ compiler and can
> bootstrap itself. I recently did a bunch of work on a Raspberry Pi and
> I needed to build CMake; no problem. I just tried to build Swift on
> the Pi. I got hit by a bug where the build process pulls in the wrong
> version of Python (2 vs 3) if 

Re: [cmake-developers] CMake alternative language

[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):
foobazifiy(MyOtherListOfSameSizeThanMyList[i])




On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet 
wrote:

> 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 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
>>> would
>>> have to understand two programs: the program itself, and the "build
>>> program".
>>
>>
>> The problem is when you have to do a real program for your build system
>> anyways (which occurs one day or another for any large enough project I
>> guess).
>> Currently it's a real pain (but it'd be even more painful to have to ship
>> Python / Bash / $script_language as part of your build system).
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[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)
> foobazify(${Element})
> endforeach()
>
Probably a bad exmple, since you're not using MyList or i that simplifies to

foreach( Element ${MyOtherListOfSameSizeThanMylist} )
foobazify( ${Element} )
endforeach()

> instead of :
>
> for i in range(0, MyList.size):
> foobazifiy(MyOtherListOfSameSizeThanMyList[i])
>
>
>
>
>
> On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet 
> wrote:
>>
>> 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
>>  a écrit :
>>>
>>>
>>> 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
 would
 have to understand two programs: the program itself, and the "build
 program".
>>>
>>>
>>> The problem is when you have to do a real program for your build system
>>> anyways (which occurs one day or another for any large enough project I
>>> guess).
>>> Currently it's a real pain (but it'd be even more painful to have to ship
>>> Python / Bash / $script_language as part of your build system).
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake-developers
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[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 made during the configure step which can then be inspected.

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[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 install
phases relate to each other, how to organise the files and targets of a
multi-target project, how to connect two projects. These would be just as
difficult to grasp in Python or Lua as it is in CMake-script.

I support replacing the CMake language but in order to lower the barrier I
think 10-20 nice, minimal sample projects would be more important.

Tamas


On Wed, Jan 13, 2016 at 2:14 PM, 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 lower it *a lot*.
>
> Thanks for sharing :)
>
>
> Le mer. 13 janv. 2016 à 10:59, yann suisini  a
> écrit :
>
>> 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 directly in
>> Ninja.
>> I had to write a python script to parse my eclipse project xml to create
>> a list of sources files usable by CMAKE.
>> The first thing I thought was: why this is not a part of cmake ? And the
>> second thing was : why not using the scripting power of an existing
>> language like Python(or other one)
>> and add CMAKE as a framework / library ?
>> Probably a dumb question ! :)
>>
>> Yann
>>
>> 2016-01-13 10:34 GMT+01:00 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 specification listing the actual
>>>   source files, dependencies, and usage requirements.  I'd like to offer
>>>   an alternative to this.
>>>
>>> In my experience, most of the elaborate macros/functions come either
>>> from a misunderstanding of some of CMake's internals (scope, link
>>> debug/release libs, etc) or to circumvent some shortcoming of the CMake
>>> language (e.g. no return value for functions).
>>>
>>> >  I'd like to improve this by *optionally* moving part of the
>>> specification
>>>   to a (stateless) declarative format that IDEs can load/edit/save
>>> directly
>>>
>>> Split the buildsystem in two different languages ? Would the declarative
>>> part be in a different file ?
>>> Also, the declarative part in my opinion must take advantage of the
>>> language.
>>> For instance, add a source file only for WIN32 systems should be easy in
>>> said declarative format.
>>> Using a custom language (based on JSON for instance) would mean to add
>>> conditionals, which comes back to making a custom language again.
>>>
>>>
>>> To come back to my first point, I understand completely that this would
>>> be a tremendous change, and the transition would be difficult to say the
>>> least. But I think it would be more than worth it in the long term.
>>>
>>> > The moment you make CMake scriptable in more than one language, you
>>> are forcing
>>> > every CMake user to learn that additional language because sooner or
>>> later he
>>> > will step into a third-party that is using that additional language.
>>>
>>> What I have in mind is to deprecate the current CMake language and
>>> replace it with another language. So there would be a transition period,
>>> but in the end there would only be one language again, and a better one.
>>>
>>> If CMake transitioned to python (or Lua, or whatever) newcomers to CMake
>>> would not need learn a new language (or at least learn one that has many
>>> resources, and can be used for other purposes).
>>> Old-timers would have to learn a new language (or maybe not, most
>>> programmers I know have played a bit with python to automate simple tasks),
>>> but this would be easier than learning CMake was, since there are
>>> established rules and a more consistent design to it.
>>>
>>> Of course I'm not saying this should happen overnight, nor am I saying
>>> this *must* happen, but I think discussing it can only be beneficial.
>>>
>>> I've seen lots of people wonder how to make their CMake scripts more
>>> efficient, and currently this is a very difficult thing to do, since there
>>> is no profiling possible.
>>> And who can say they never spent way too much time trying to understand
>>> why a variable was not correctly initialized ? When the configure step

Re: [cmake-developers] CMake alternative language

[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 'I understand that it would be difficult' but ... not
really, if the first word isn't a 'keyword' (Function/Macro name) then
if the next token is a = instead of a ( then assume it's a SET 

-
Re: "no return values for functions"  that's not true... this script
sets the return value just fine...

---
cmake_minimum_required( VERSION 3.0 )

macro( SomeFunc ReturnVal )
   set( ${ReturnVal} SomeResult )
endmacro( SomeFunc )

SomeFunc( RetVal )
message( "and we have a result of " ${RetVal} )

output : and we have a result of SomeResult

-
J/K : I think the alternative language should be LISP; oh wait that's
already what it is. other than the function is outside of the parens

One of the last comments mentioned something about the named
parameters passed to methods like

SET_TARGET_PROPERTIES(${project} PROPERTIES
  FOLDER utils
  COMPILE_DEFINTIIONS "SomeOtherSyms"
)

Is at first a little confusing... but at least I don't have some
required order where I have to isnert a bunch of blank ',,' to get
to the option I want to use.

It might be nice if there were methods to define your own syntax for
these things for use in passing options to MACRO where as you iterate
through the ARGN members it can trigger some sort of state table
lookup/dispatch... but then I really don't have a use for such a thing
in the reality of switching to cmake maybe 5 years ago.

Re: Profile-ability of CMake.  I haven't yet found anywhere that I
would blame any part of the build process slowness on CMAKE, but
rather on the build tools themselves (CygWin or MinGW for instances).
Although... there is One project I often rebuild (OpenAL) which uses a
bunch of CHECK_FUNCTION_EXISTS(snprintf HAVE_SNPRINTF) which seems to
be pretty slow.   But Really, I think the target rules would be better
to test CMAKE_COMPILER_IS_ and WIN32/UNIX variables to get that
result.  There's certainly less permutations to test that way than
testing for each function that might exist; since the variations are
limited to environments (each generator) with perhaps a minor off case
for some toolchains.  But I guess that was put in to satisy autotool
people coming to a different build system.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[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 specification listing the actual
  source files, dependencies, and usage requirements.  I'd like to offer
  an alternative to this.

In my experience, most of the elaborate macros/functions come either from a
misunderstanding of some of CMake's internals (scope, link debug/release
libs, etc) or to circumvent some shortcoming of the CMake language (e.g. no
return value for functions).

>  I'd like to improve this by *optionally* moving part of the specification
  to a (stateless) declarative format that IDEs can load/edit/save directly

Split the buildsystem in two different languages ? Would the declarative
part be in a different file ?
Also, the declarative part in my opinion must take advantage of the
language.
For instance, add a source file only for WIN32 systems should be easy in
said declarative format.
Using a custom language (based on JSON for instance) would mean to add
conditionals, which comes back to making a custom language again.


To come back to my first point, I understand completely that this would be
a tremendous change, and the transition would be difficult to say the
least. But I think it would be more than worth it in the long term.

> The moment you make CMake scriptable in more than one language, you are
forcing
> every CMake user to learn that additional language because sooner or
later he
> will step into a third-party that is using that additional language.

What I have in mind is to deprecate the current CMake language and replace
it with another language. So there would be a transition period, but in the
end there would only be one language again, and a better one.

If CMake transitioned to python (or Lua, or whatever) newcomers to CMake
would not need learn a new language (or at least learn one that has many
resources, and can be used for other purposes).
Old-timers would have to learn a new language (or maybe not, most
programmers I know have played a bit with python to automate simple tasks),
but this would be easier than learning CMake was, since there are
established rules and a more consistent design to it.

Of course I'm not saying this should happen overnight, nor am I saying this
*must* happen, but I think discussing it can only be beneficial.

I've seen lots of people wonder how to make their CMake scripts more
efficient, and currently this is a very difficult thing to do, since there
is no profiling possible.
And who can say they never spent way too much time trying to understand why
a variable was not correctly initialized ? 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.
I have seen some hardly understandable CMake code, and only thanks to the
git history was I able to understand that the person who wrote the script
completely misunderstood the CMake language.

>As discussed above if some kind of callback or user-coded function needs to
be included for advanced usage of the declarative spec then we would need
a language for it.  The current CMake language is not well suited to that
use case (e.g. no expressions or return values), so an existing alternative
language should be chosen.

>CMake's current "generator expressions" fill this role somewhat now and are
essentially a sub-language.  As with the main language they grew out of
something not intended to serve their current full role.  They could be
superseded by a common alternative generate-time language too.

These points are part of the reason I think a new language should be used,
if it can cover all of these issues. I'd rather not see a new CMake
declarative language that might itself grow out and become something
difficult to grasp.
Something like generator expressions could be expressed in a language such
as python or lua, by using objects that get resolved at generate time (or
functions, or whatever).


Cheers

Le lun. 11 janv. 2016 à 21:53, Brad King  a écrit :

> 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.cmake.devel/15339/focus=15386
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389
>
> General comments:
>
> * 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.
>
> * CMake's procedural/imperative design is good as the main entry point to
>   

Re: [cmake-developers] CMake alternative language

[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 à 10:59, yann suisini  a
écrit :

> 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 directly in
> Ninja.
> I had to write a python script to parse my eclipse project xml to create a
> list of sources files usable by CMAKE.
> The first thing I thought was: why this is not a part of cmake ? And the
> second thing was : why not using the scripting power of an existing
> language like Python(or other one)
> and add CMAKE as a framework / library ?
> Probably a dumb question ! :)
>
> Yann
>
> 2016-01-13 10:34 GMT+01:00 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 specification listing the actual
>>   source files, dependencies, and usage requirements.  I'd like to offer
>>   an alternative to this.
>>
>> In my experience, most of the elaborate macros/functions come either from
>> a misunderstanding of some of CMake's internals (scope, link debug/release
>> libs, etc) or to circumvent some shortcoming of the CMake language (e.g. no
>> return value for functions).
>>
>> >  I'd like to improve this by *optionally* moving part of the
>> specification
>>   to a (stateless) declarative format that IDEs can load/edit/save
>> directly
>>
>> Split the buildsystem in two different languages ? Would the declarative
>> part be in a different file ?
>> Also, the declarative part in my opinion must take advantage of the
>> language.
>> For instance, add a source file only for WIN32 systems should be easy in
>> said declarative format.
>> Using a custom language (based on JSON for instance) would mean to add
>> conditionals, which comes back to making a custom language again.
>>
>>
>> To come back to my first point, I understand completely that this would
>> be a tremendous change, and the transition would be difficult to say the
>> least. But I think it would be more than worth it in the long term.
>>
>> > The moment you make CMake scriptable in more than one language, you are
>> forcing
>> > every CMake user to learn that additional language because sooner or
>> later he
>> > will step into a third-party that is using that additional language.
>>
>> What I have in mind is to deprecate the current CMake language and
>> replace it with another language. So there would be a transition period,
>> but in the end there would only be one language again, and a better one.
>>
>> If CMake transitioned to python (or Lua, or whatever) newcomers to CMake
>> would not need learn a new language (or at least learn one that has many
>> resources, and can be used for other purposes).
>> Old-timers would have to learn a new language (or maybe not, most
>> programmers I know have played a bit with python to automate simple tasks),
>> but this would be easier than learning CMake was, since there are
>> established rules and a more consistent design to it.
>>
>> Of course I'm not saying this should happen overnight, nor am I saying
>> this *must* happen, but I think discussing it can only be beneficial.
>>
>> I've seen lots of people wonder how to make their CMake scripts more
>> efficient, and currently this is a very difficult thing to do, since there
>> is no profiling possible.
>> And who can say they never spent way too much time trying to understand
>> why a variable was not correctly initialized ? 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.
>> I have seen some hardly understandable CMake code, and only thanks to the
>> git history was I able to understand that the person who wrote the script
>> completely misunderstood the CMake language.
>>
>> >As discussed above if some kind of callback or user-coded function needs
>> to
>> be included for advanced usage of the declarative spec then we would need
>> a language for it.  The current CMake language is not well suited to that
>> use case (e.g. no expressions or return values), so an existing
>> alternative
>> language should be chosen.
>>
>> >CMake's current "generator expressions" fill this role somewhat now and
>> are
>> essentially a sub-language.  As 

Re: [cmake-developers] CMake alternative language

[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 lower it *a lot*.

Personally I'm determinant to use CMake, mostly due to its maturity and 
CPack's features, but recently stumbled upon Meson http://mesonbuild.com/) 
build system whose goal is "to be both extremely fast, and, even more 
importantly, as user friendly as possible."...it also uses Ninja instead 
of Make as backend.

Otoh, I believe that main problem with CMake is lack of quality docs - even 
Mastering CMake book has constantly very bad reviews.

Sincerely,
Gour


-- 
One who sees inaction in action, and action in inaction, 
is intelligent among men, and he is in the transcendental position, 
although engaged in all sorts of activities.




-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[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 , ant at
> the end the CMAKE description is longer than the one I built directly in
> Ninja.
> I had to write a python script to parse my eclipse project xml to create a
> list of sources files usable by CMAKE.
> The first thing I thought was: why this is not a part of cmake ? And the
> second thing was : why not using the scripting power of an existing
> language like Python(or other one) and add CMAKE as a framework / library ?

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 would 
have to understand two programs: the program itself, and the "build program".

I'm not saying that the cmake language is beautiful, but it helps to keep 
cmake scripts somewhat simple, and not evolve into a second program 
additionally to the actual program which is being built.

Alex

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[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 a lot
of unique setups we have (which were largely inherited from a previous
inhouse buildsystem). Yes, the end result of our framework is that the
CMakeLists consist mostly of declarative commands from our framework, but
the implementation of these commands is heavily procedural. I am convinced
that if CMake didn't give us the procedural power required to make this
work, we couldn't have adopted it. (I had previously tried emulating bits
of this setup in a more declarative system and failed miserably).

Of course (having written much of this framework I'm talking about above),
I know all too well that a better front-end language would do a world of
good for CMake. I also understand that taking a more declarative approach
could help that, and I'm not opposed to such a change in principle.
However, please take care not to throw the baby out with the bathwater and
nerf the expressiveness of what can be done with CMake (in a procedural
way).

If I understand Brad's suggestion correctly, it would amount to a (possibly
empty) procedural step being used to generate a declarative description of
the buildsystem. This would work well in our scenario, I believe, as long
as that procedural step could be sufficiently modularised on the client
side.

I fully support introducing an alternative input language to CMake and
taking all steps necessary for this to happen, but please do this in a way
which will not restrict what CMake is capable of doing.

Petr

On Fri, Jan 8, 2016 at 5:30 PM, Brad King  wrote:

> 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 is a long
> way to go.
>
> A few general thoughts:
>
> * One rule we have for CMake is to never expose any public SDK of the C++
>   implementation structures.  We want to be able to rewrite them
> arbitrarily
>   at any time.  Therefore any solution that needs to access the C++
>   structures must be integrated into CMake upstream and expose
> functionality
>   only through other languages or file formats.
>
> * 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 do
>   not fully control unless it is allowed to execute only in isolated and
>   independent snippets.  These are not hard goals, but it is a trade-off
>   to keep in mind.  Stephen may be able to elaborate more on the snapshot
>   approach if needed.
>
> * A problem with the current design is that the entire configuration
> process
>   is logically serial making parallel evaluation hard or impossible.  In
>   many cases each add_subdirectory can be processed independently, but this
>   will require semantic changes to allow.
>
> On 01/04/2016 02:41 AM, Charles Huet wrote:
> > I'm trying to be as declarative as possible, because really like how
> readable
> > simple QML programs are, and I think it would be perfect for a
> buildsystem.
>
> Ideally most of the specification (sources, libraries, executables, etc.)
> should be in a pure format that can be evaluated without side effects (e.g.
> declarative or functional).  This rules out both Python and Lua, but the
> specification format does not have to be the main entry point.  There could
> be some imperative configuration step that does system introspection and
> then loads the pure specification and evaluates it as needed for the
> specific
> environment.
>
> If we're going to go through the effort to provide an alternative input
> format,
> I think we should strive for this approach because it will be more
> flexible in
> the long run.  A pure specification format will allow easy loading/saving
> by
> other tools, IDEs, etc., without having to process any imperative logic.
>
> > Actually, I'm directly using the cmMakefile, because I did not want to
> wrap all
> > the commands, and it seemed backwards to me to wrap them.
>
> Yes.  Any alternative format should be processed directly into the
> structures
> used by the generators.  The cmState work has separated the generate-time
> representation quite a bit from the configuration-time
> (cmake-language-specific)
> representation, but I think there is still further work needed to finish
> that.
>
> >> Having said all that, Brad favors Lua I believe, and he favors a
> different
> >> approach 

Re: [cmake-developers] CMake alternative language

[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
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389

General comments:

* 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.

* CMake's procedural/imperative design is good as the main entry point to
  configuration of a project.  It can do system introspection, file generation,
  etc.  I'm not proposing that this change.

* Many projects build elaborate macro/function systems in the CMake language
  in order to end up with a declarative specification listing the actual
  source files, dependencies, and usage requirements.  I'd like to offer
  an alternative to this.

* Integration with IDEs is currently based on one-way generation (VS IDE
  projects, Xcode projects, CodeBlocks, etc.).  Editing the project build
  specification requires editing CMake code directly because IDEs cannot
  easily pierce CMake's procedural/imperative specification:

https://cmake.org/pipermail/cmake-developers/2016-January/027386.html

  I'd like to improve this by *optionally* moving part of the specification
  to a (stateless) declarative format that IDEs can load/edit/save directly.

Specific responses follow.



On 01/11/2016 12:24 PM, Charles Huet wrote:
> I think these goals aim towards a faster configure, and the ability to
> only partly reconfigure, right?

Yes.

> I know I am largely biased by the project I work on, but I do not see how
> parallel evaluation woud be a huge benefit.
[snip]
> And how would that work with CMakeLists that affect their parent scope ?

Evaluation of the imperative language is currently serial for reasons like
this, which is why I said it would take semantic changes to enable parallel
evaluation. This is not the main point of my proposal so I'd rather not
get bogged down in the details of this part of the discussion.

>> Ideally most of the specification (sources, libraries, executables, etc.)
>> should be in a pure format that can be evaluated without side effects (e.g.
>> declarative or functional).
>
> I'm not sure I understand how this could be done without losing a lot of
> what CMake offers, such as copying or generating files.

I'm not proposing dropping the current imperative capabilities.

> I'm leaning towards a declarative approach as it is quite easy to learn
> (since you declare objects, and every C++ programmer I know is familiar
> with those)

Yes.

> It seems you are leaning towards pure functional, but I do not see how
> this would work with the current way CMake handles variables and scope,
> could you elaborate ?

While declarative may get us most of the way, advanced users may wish to
hook in to generation-time evaluation. A clean way to do that would be
to specify a function within the declared values. It would not have to
be in a functional language as long as it has no access to anything other
than the inputs passed to it during evaluation.

I mentioned "functional" mostly as an example of a specification whose
evaluation is free of side effects.

> To clarify, only the following lines should be considered when looking at the 
> POC.
>> myProject=cmake.Project("MyTestProject")
>> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])]

Yes, this is the kind of stuff that can be in a declarative format.

> It seems you have in mind to write a new CMake language.

No, at most a new specification format that can be used for IDE integration.
If some kind of user-coded function were included in the specification it
should certainly be in an existing language.

> Maybe I should take my POC further

I think implementation even of a POC is premature at this point.  We
should explore the design space further.

> CMake's own buildsystem seems like a good testing ground for this, but
> it is a little too big for a first go, do you know of a small CMake-based
> project that would be better suited ?

Maybe you could find something in our test suite.

> I don't have a clear view of what a pure functional CMake would look like,
> but if you give me some mock code, I could give a try at bringing some pure
> functional language up to the level of my POC and we could use it as a more
> concrete discussion support.

I have no prototype (nor substantial time to spend on design myself) but
I've imagined a declarative format in a well-known syntax (e.g. JSON or one
of the lightweight human-friendly choices).  If generate-time functionality
is needed then code snippets in e.g. Lua could be included.

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

[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 we do
  not fully control unless it is allowed to execute only in isolated and
  independent snippets.  These are not hard goals, but it is a trade-off
  to keep in mind.  Stephen may be able to elaborate more on the snapshot
  approach if needed.

I think these goals aim towards a faster configure, and the ability to only
partly reconfigure, right ?

> * A problem with the current design is that the entire configuration
process
  is logically serial making parallel evaluation hard or impossible.  In
  many cases each add_subdirectory can be processed independently, but this
  will require semantic changes to allow.

I know I am largely biased by the project I work on, but I do not see how
parallel evaluation woud be a huge benefit. We basically have a "core"
library, and lots of libs that link against it (and other libs, such as
third parties).
How would a target B that depends on lib A be processed in this case ?
Wouldn't the evaluation of the link_libraries of B be waiting for the
evaluation of A to finish ?
If this is the case, then parallel evaluation would be only a slight
benefit (again, heavily biased by the project I work on).
And how would that work with CMakeLists that affect their parent scope ?

> Ideally most of the specification (sources, libraries, executables, etc.)
should be in a pure format that can be evaluated without side effects (e.g.
declarative or functional).

I'm not sure I understand how this could be done without losing a lot of
what CMake offers, such as copying or generating files.
I'm leaning towards a declarative approach as it is quite easy to learn
(since you declare objects, and every C++ programmer I know is familiar
with those), and functional, while powerfull and very elegant for some
things, is quite foreign to C+ programmers as a whole (I know C++11 adds
this, but it will be years until this can be used in production for lots of
C++ users, because of old compilers that are still supported for business
reasons).
Moreover, object-oriented is easy to introspect, offering an abstract
representation for IDEs and tools.

It seems you are leaning towards pure functional, but I do not see how this
would work with the current way CMake handles variables and scope, could
you elaborate ?


> I do not think we should have the build specification depend on processing
code like this.  It is not compatible with cmake-gui where the configuration
and generation steps are triggered by the user.

My POC is far from complete, and what I had in mind to keep the CMake-gui
approach was to make generating optional in CLI through a parameter. Thus
executing the script would only configure, which would populate the
CMakeCache, allowing the user to modify variables and such, then configure.
To clarify, only the following lines should be considered when looking at
the POC.
> myProject=cmake.Project("MyTestProject")
> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])]


> In summary, I think work in this direction should first focus on designing
a declarative (or functional) specification format where most of the project
information can be specified.  Then a cmake-language command can be written
to load and evaluate a specification file (as a transition).  Finally we
could look at replacing the entry-point language with something else.  At
that point we could have closures passed as parameters to the evaluation of
the pure spec in order to get custom generate-time logic.

It seems you have in mind to write a new CMake language. I'd rather see an
existing language used, such as OCaml or lisp if you want a pure functional
language. Those are supported by SWIG so prototyping would be easy.
Javascript is even an option that is not *completely* crazy, as it has a
C-Style syntax  so it would be an easy language to write in for C++
programmers.

I think using an existing language has quite a few benefits:
* no need to design or implement a language
* lots of existing resources on how to do things
* lots of existing libraries (data structures, file system operations, etc)
* tooling (auto-complete, debugging, profiling, linting, etc)

Maybe I should take my POC further, in order to see the failings of this
approach, and maybe the same should be done for a more functional approach.
CMake's own buildsystem seems like a good testing ground for this, but it
is a little too big for a first go, do you know of a small CMake-based
project that would be better suited ?

I don't have a clear view of what a pure functional CMake would look like,
but if you give me some mock code, I could give a try at bringing some pure
functional language up to the level of my POC and we could use it as a more

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

[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 CMake
> language
> in a clean way, but that will not be as valuable as the above pure-spec
> approach.
>
>
Please, do not do that.

The moment you make CMake scriptable in more than one language, you are
forcing every CMake user to learn that additional language because sooner
or later he will step into a third-party that is using that additional
language.

IMHO, if you want Lua, then Lua it is. But then please get rid of CMake
scripting.

BTW, I am sure you are aware of CMakeScript, CMake scripting in JavaScript:

http://sourceforge.net/projects/cmakescript/

Also, declarative? Why? There are already a few declarative build systems
(e. g. qbs, one of the reasons for its existence was CMake was not
declarative). By moving CMake from the current procedural scripting to a
declarative approach, you may alienate your current user base and be good
for none anymore.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[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 is a long
way to go.

A few general thoughts:

* One rule we have for CMake is to never expose any public SDK of the C++
  implementation structures.  We want to be able to rewrite them arbitrarily
  at any time.  Therefore any solution that needs to access the C++
  structures must be integrated into CMake upstream and expose functionality
  only through other languages or file formats.

* 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 do
  not fully control unless it is allowed to execute only in isolated and
  independent snippets.  These are not hard goals, but it is a trade-off
  to keep in mind.  Stephen may be able to elaborate more on the snapshot
  approach if needed.

* A problem with the current design is that the entire configuration process
  is logically serial making parallel evaluation hard or impossible.  In
  many cases each add_subdirectory can be processed independently, but this
  will require semantic changes to allow.

On 01/04/2016 02:41 AM, Charles Huet wrote:
> I'm trying to be as declarative as possible, because really like how readable
> simple QML programs are, and I think it would be perfect for a buildsystem.

Ideally most of the specification (sources, libraries, executables, etc.)
should be in a pure format that can be evaluated without side effects (e.g.
declarative or functional).  This rules out both Python and Lua, but the
specification format does not have to be the main entry point.  There could
be some imperative configuration step that does system introspection and
then loads the pure specification and evaluates it as needed for the specific
environment.

If we're going to go through the effort to provide an alternative input format,
I think we should strive for this approach because it will be more flexible in
the long run.  A pure specification format will allow easy loading/saving by
other tools, IDEs, etc., without having to process any imperative logic.

> Actually, I'm directly using the cmMakefile, because I did not want to wrap 
> all
> the commands, and it seemed backwards to me to wrap them.

Yes.  Any alternative format should be processed directly into the structures
used by the generators.  The cmState work has separated the generate-time
representation quite a bit from the configuration-time (cmake-language-specific)
representation, but I think there is still further work needed to finish that.

>> Having said all that, Brad favors Lua I believe, and he favors a different
>> approach (which no one is working on as far as I know) to adding a new
>> language. So wait to hear from him to know whether it is something that
>> would be upstreamable.
> 
> Have any details on the approach in question?

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 clean way, but that will not be as valuable as the above pure-spec 
approach.

> Here is what my test POC looked like for generating a simple shared library:
> 
> #!/usr/bin/env python
> # -*- coding: utf-8 -*-
> importcmake
> 
> cmake.init("Ninja","/media/dev/src/cmaketest","/media/dev/build/cmaketest")
> myProject=cmake.Project("MyTestProject")
> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])]
> cmake.generate()

I do not think we should have the build specification depend on processing
code like this.  It is not compatible with cmake-gui where the configuration
and generation steps are triggered by the user.  However, this does serve
as a good POC that we can populate the generator structures with another
language.

In summary, I think work in this direction should first focus on designing
a declarative (or functional) specification format where most of the project
information can be specified.  Then a cmake-language command can be written
to load and evaluate a specification file (as a transition).  Finally we
could look at replacing the entry-point language with something else.  At
that point we could have closures passed as parameters to the evaluation of
the pure spec in order to get custom generate-time logic.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on