<div dir="ltr">Hi,<div><br></div><div>I'm a new user of CMake, but I just want to express my newcomer point of view.</div><div>Honestly , I can feel the power of CMAKE, but it's a real pain to learn ...</div><div>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.</div><div>I had to write a python script to parse my eclipse project xml to create a list of sources files usable by CMAKE.</div><div>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)</div><div>and add CMAKE as a framework / library ? </div><div>Probably a dumb question ! :)</div><div><br></div><div>Yann</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-13 10:34 GMT+01:00 Charles Huet <span dir="ltr"><<a href="mailto:charles.huet@gmail.com" target="_blank">charles.huet@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<span class=""><div dir="ltr"><div><br></div><div><span style="font-size:13px;line-height:19.5px">> * There is a lot of code out there in the current CMake language so I do not</span><br style="font-size:13px;line-height:19.5px"><span style="font-size:13px;line-height:19.5px">  think it is realistic to drop it.  I'm not proposing that this change.</span><br></div><div><br></div></div></span><div dir="ltr"><div>I am. (more below)</div></div><span class=""><div dir="ltr"><div><br></div><div>> * Many projects build elaborate macro/function systems in the CMake language<br>  in order to end up with a declarative specification listing the actual<br>  source files, dependencies, and usage requirements.  I'd like to offer<br>  an alternative to this.<br></div><div><br></div></div></span><div dir="ltr"><div>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).</div></div><span class=""><div dir="ltr"><div><br></div><div>>  I'd like to improve this by *optionally* moving part of the specification</div>  to a (stateless) declarative format that IDEs can load/edit/save directly<div><br></div></div></span><div dir="ltr"><div>Split the buildsystem in two different languages ? Would the declarative part be in a different file ?</div><div>Also, the declarative part in my opinion must take advantage of the language. </div><div>For instance, add a source file only for WIN32 systems should be easy in said declarative format.</div><div>Using a custom language (based on JSON for instance) would mean to add conditionals, which comes back to making a custom language again.</div><div><br></div><div><br></div><div>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.</div></div><span class=""><div dir="ltr"><div><br></div><div>> The moment you make CMake scriptable in more than one language, you are forcing<br>> every CMake user to learn that additional language because sooner or later he<br>> will step into a third-party that is using that additional language.<br></div><div><br></div></div></span><div dir="ltr"><div>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.</div><div><br></div><div>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).</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div>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.</div></div><span class=""><div dir="ltr"><div><br></div><div>>As discussed above if some kind of callback or user-coded function needs to</div>be included for advanced usage of the declarative spec then we would need<br>a language for it.  The current CMake language is not well suited to that<br>use case (e.g. no expressions or return values), so an existing alternative<br>language should be chosen.<br><br>>CMake's current "generator expressions" fill this role somewhat now and are<br>essentially a sub-language.  As with the main language they grew out of<br>something not intended to serve their current full role.  They could be<br>superseded by a common alternative generate-time language too.<div><br></div></div></span><div dir="ltr"><div>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.</div><div>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).</div><div><br></div><div><br></div><div>Cheers</div></div><div><div class="h5"><div dir="ltr"><div><br></div><div class="gmail_quote"><div dir="ltr">Le lun. 11 janv. 2016 à 21:53, Brad King <<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Folks,<br>
<br>
I'm replying directly to my previous post in this thread in order to consolidate<br>
responses to related discussion raised in others' responses to it:<br>
<br>
 <a href="http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383" rel="noreferrer" target="_blank">http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383</a><br>
 <a href="http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386" rel="noreferrer" target="_blank">http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386</a><br>
 <a href="http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389" rel="noreferrer" target="_blank">http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389</a><br>
<br>
General comments:<br>
<br>
* There is a lot of code out there in the current CMake language so I do not<br>
  think it is realistic to drop it.  I'm not proposing that this change.<br>
<br>
* CMake's procedural/imperative design is good as the main entry point to<br>
  configuration of a project.  It can do system introspection, file generation,<br>
  etc.  I'm not proposing that this change.<br>
<br>
* Many projects build elaborate macro/function systems in the CMake language<br>
  in order to end up with a declarative specification listing the actual<br>
  source files, dependencies, and usage requirements.  I'd like to offer<br>
  an alternative to this.<br>
<br>
* Integration with IDEs is currently based on one-way generation (VS IDE<br>
  projects, Xcode projects, CodeBlocks, etc.).  Editing the project build<br>
  specification requires editing CMake code directly because IDEs cannot<br>
  easily pierce CMake's procedural/imperative specification:<br>
<br>
    <a href="https://cmake.org/pipermail/cmake-developers/2016-January/027386.html" rel="noreferrer" target="_blank">https://cmake.org/pipermail/cmake-developers/2016-January/027386.html</a><br>
<br>
  I'd like to improve this by *optionally* moving part of the specification<br>
  to a (stateless) declarative format that IDEs can load/edit/save directly.<br>
<br>
Specific responses follow.<br>
<br>
--------------------------------------------------------------------------------<br>
<br>
On 01/11/2016 12:24 PM, Charles Huet wrote:<br>
> I think these goals aim towards a faster configure, and the ability to<br>
> only partly reconfigure, right?<br>
<br>
Yes.<br>
<br>
> I know I am largely biased by the project I work on, but I do not see how<br>
> parallel evaluation woud be a huge benefit.<br>
[snip]<br>
> And how would that work with CMakeLists that affect their parent scope ?<br>
<br>
Evaluation of the imperative language is currently serial for reasons like<br>
this, which is why I said it would take semantic changes to enable parallel<br>
evaluation. This is not the main point of my proposal so I'd rather not<br>
get bogged down in the details of this part of the discussion.<br>
<br>
>> Ideally most of the specification (sources, libraries, executables, etc.)<br>
>> should be in a pure format that can be evaluated without side effects (e.g.<br>
>> declarative or functional).<br>
><br>
> I'm not sure I understand how this could be done without losing a lot of<br>
> what CMake offers, such as copying or generating files.<br>
<br>
I'm not proposing dropping the current imperative capabilities.<br>
<br>
> I'm leaning towards a declarative approach as it is quite easy to learn<br>
> (since you declare objects, and every C++ programmer I know is familiar<br>
> with those)<br>
<br>
Yes.<br>
<br>
> It seems you are leaning towards pure functional, but I do not see how<br>
> this would work with the current way CMake handles variables and scope,<br>
> could you elaborate ?<br>
<br>
While declarative may get us most of the way, advanced users may wish to<br>
hook in to generation-time evaluation. A clean way to do that would be<br>
to specify a function within the declared values. It would not have to<br>
be in a functional language as long as it has no access to anything other<br>
than the inputs passed to it during evaluation.<br>
<br>
I mentioned "functional" mostly as an example of a specification whose<br>
evaluation is free of side effects.<br>
<br>
> To clarify, only the following lines should be considered when looking at the POC.<br>
>>     myProject=cmake.Project("MyTestProject")<br>
>>     myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])]<br>
<br>
Yes, this is the kind of stuff that can be in a declarative format.<br>
<br>
> It seems you have in mind to write a new CMake language.<br>
<br>
No, at most a new specification format that can be used for IDE integration.<br>
If some kind of user-coded function were included in the specification it<br>
should certainly be in an existing language.<br>
<br>
> Maybe I should take my POC further<br>
<br>
I think implementation even of a POC is premature at this point.  We<br>
should explore the design space further.<br>
<br>
> CMake's own buildsystem seems like a good testing ground for this, but<br>
> it is a little too big for a first go, do you know of a small CMake-based<br>
> project that would be better suited ?<br>
<br>
Maybe you could find something in our test suite.<br>
<br>
> I don't have a clear view of what a pure functional CMake would look like,<br>
> but if you give me some mock code, I could give a try at bringing some pure<br>
> functional language up to the level of my POC and we could use it as a more<br>
> concrete discussion support.<br>
<br>
I have no prototype (nor substantial time to spend on design myself) but<br>
I've imagined a declarative format in a well-known syntax (e.g. JSON or one<br>
of the lightweight human-friendly choices).  If generate-time functionality<br>
is needed then code snippets in e.g. Lua could be included.<br>
<br>
--------------------------------------------------------------------------------<br>
<br>
Petr Kmoch wrote:<br>
> I'd like to voice my opinion as a somewhat advanced CMake user here.<br>
<br>
Thanks for joining the discussion with this point of view.<br>
<br>
> For me, one of the strongest points of CMake is the fact that its project<br>
> specification is procedural rather than declarative.<br>
<br>
Good. We will not be dropping imperative capabilities.<br>
<br>
> end result of our framework is that the CMakeLists consist mostly of<br>
> declarative commands from our framework<br>
<br>
Yes, many projects have such frameworks. Most of them result in a<br>
declarative spec inside calls to their macros/functions. I'd like to<br>
formalize such specs in a re-usable way.<br>
<br>
> If I understand Brad's suggestion correctly, it would amount to a<br>
> (possibly empty) procedural step being used to generate a declarative<br>
> description of the buildsystem.<br>
<br>
Not quite. Yes, the procedural/imperative part would still be the entry<br>
point as it is now. However, the declarative part would also be an<br>
input, not an output. The procedural part's role would be to compute<br>
*parameters* to be used for the evaluation of the declarative spec.<br>
<br>
For example, imagine the declarative spec somehow encodes that source<br>
file "foo.c" is optional based on some condition "FOO". The value of<br>
that condition could be computed by the procedural part of the process<br>
based on system introspection, command-line options, etc., and then<br>
provided to CMake for use in the final evaluation.<br>
<br>
--------------------------------------------------------------------------------<br>
<br>
On 01/11/2016 01:21 PM, Pau Garcia i Quiles wrote:<br>
> The moment you make CMake scriptable in more than one language, you are forcing<br>
> every CMake user to learn that additional language because sooner or later he<br>
> will step into a third-party that is using that additional language.<br>
<br>
I don't think the main "entry point" language should be selectable.<br>
<br>
As discussed above if some kind of callback or user-coded function needs to<br>
be included for advanced usage of the declarative spec then we would need<br>
a language for it.  The current CMake language is not well suited to that<br>
use case (e.g. no expressions or return values), so an existing alternative<br>
language should be chosen.<br>
<br>
CMake's current "generator expressions" fill this role somewhat now and are<br>
essentially a sub-language.  As with the main language they grew out of<br>
something not intended to serve their current full role.  They could be<br>
superseded by a common alternative generate-time language too.<br>
<br>
> Also, declarative? Why?<br>
<br>
See above.<br>
<br>
> There are already a few declarative build systems<br>
<br>
Yes, and perhaps we can learn from their formats for the proposed declarative<br>
part.<br>
<br>
> qbs, one of the reasons for its existence was CMake was not declarative<br>
<br>
IIUC that is exactly because of the fact that an imperative spec cannot<br>
be pierced easily for editing in IDEs.<br>
<br>
--------------------------------------------------------------------------------<br>
<br>
Thanks all for the discussion so far!<br>
<br>
-Brad<br>
<br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake-developers</a><br>
</blockquote></div></div></div></div></div>
<br>--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake-developers</a><br></blockquote></div><br></div>