<div dir="ltr">Charles,<div><br></div><div>I'd like to comment on a minor issue:</div><div><br></div><div>CMakeLists.txt files don't specify user-specific data like source and build dirs (for a reason) yet your POC listfile contains this line:</div><div><br></div><div><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">    cmake</span><span style="font-size:12.8px;color:rgb(0,0,0)">.</span><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">init</span><span style="font-size:12.8px;color:rgb(0,0,0)">(</span><span style="font-size:12.8px;color:rgb(0,128,0)">"Ninja"</span><span style="font-size:12.8px;color:rgb(0,0,0)">,</span><span style="font-size:12.8px;color:rgb(192,192,192)"> </span><span style="font-size:12.8px;color:rgb(0,128,0)">"/media/dev/src/cmaketest"</span><span style="font-size:12.8px;color:rgb(0,0,0)">,</span><span style="font-size:12.8px;color:rgb(192,192,192)"> </span><span style="font-size:12.8px;color:rgb(0,128,0)">"/media/dev/build/cmaketest"</span><span style="font-size:12.8px;color:rgb(0,0,0)">)</span><br style="font-size:12.8px"></div><div><span style="font-size:12.8px;color:rgb(0,0,0)"><br></span></div><div><font color="#000000"><span style="font-size:12.8px">which sets the source and build directories. Is this some temporary solution for the POC only?</span></font></div><div><font color="#000000"><span style="font-size:12.8px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.8px">Tamas<br></span></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 4, 2016 at 8:41 AM, Charles Huet <span dir="ltr"><<a href="mailto:charles.huet@gmail.com" target="_blank">charles.huet@gmail.com</a>></span> wrote:<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><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Because of the above, I worry that you are basing your work on an old<br>version of CMake. As of April 2015 cmState is used as the interface to the<br>cache.</blockquote><div><br></div></span><div>Yeah, that is sadly right. I wanted to rebase on master before publishing, thinking it should not be too hard, and I have lots to re-do, mostly understand how things are done now.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I did something similar some years ago with QML instead of python, so it<br>sounds interesting to me.</blockquote><div><br></div></span><div>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.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">My guess is that you are using python to instantiate a cmAddLibraryCommand<br>and then executing it. </blockquote><div><br></div></span><div>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.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Even much of cmMakefile shouldn't be used by a new language. Instead certain<br>parts of cmMakefile should be extracted as other classes (cmVariableExpander<br>which should have the ExpandVariablesInString and ConfigureString stuff,<br>cmMessenger for the IssueMessage stuff, some other class for the<br>CompileFeature stuff etc). Then cmMakefile would be just about executing and<br>scoping the CMake language. A new language would not need that, but would<br>use the refactored extracted classes.</blockquote><div><br></div></span><div>Ah, this is very interesting, thanks.</div><span class=""><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Having said all that, Brad favors Lua I believe, and he favors a different<br>approach (which no one is working on as far as I know) to adding a new<br>language. So wait to hear from him to know whether it is something that<br>would be upstreamable.</blockquote><div><br></div></span><div>Have any details on the approach in question ? SWIG would allow for Lua bindings as easily, but I don't think having multiple languages would be a good idea.</div><div>I went with Python because I'm familiar with it and have already written bindings for it with SWIG. Also, buildbot is written in python and it could provide a really interesting integration I think.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I would guide/support you in refactoring cmake as needed. The refactoring<br>part would definitely be upstreamable. I would very much like to see a proof<br>of concept alternative language even if that wasn't upstreamed. It would<br>prove that another language is possible, and that's one of the steps to<br>replacing the current cmake language I think.</blockquote><div><br></div></span><div>I will need to work on it to make it work again with master, but I'll try and do this soon.</div><div><br></div><div>Here is what my test POC looked like for generating a simple shared library:</div><div><br></div><div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote"><span style="color:rgb(0,128,0)">#!/usr/bin/env python<br></span><span style="color:rgb(0,128,0)"># -*- coding: utf-8 -*-</span><br><span style="color:rgb(128,128,0)">import</span><span style="color:rgb(192,192,192)"> </span><span style="color:rgb(0,128,0)">cmake</span><br><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">cmake</span><span style="color:rgb(0,0,0)">.</span><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">init</span><span style="color:rgb(0,0,0)">(</span><span style="color:rgb(0,128,0)">"Ninja"</span><span style="color:rgb(0,0,0)">,</span><span style="color:rgb(192,192,192)"> </span><span style="color:rgb(0,128,0)">"/media/dev/src/cmaketest"</span><span style="color:rgb(0,0,0)">,</span><span style="color:rgb(192,192,192)"> </span><span style="color:rgb(0,128,0)">"/media/dev/build/cmaketest"</span><span style="color:rgb(0,0,0)">)</span><br><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">myProject</span><span style="color:rgb(192,192,192)"> </span><span style="color:rgb(0,0,0)">=</span><span style="color:rgb(192,192,192)"> </span><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">cmake</span><span style="color:rgb(0,0,0)">.</span><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">Project</span><span style="color:rgb(0,0,0)">(</span><span style="color:rgb(0,128,0)">"MyTestProject"</span><span style="color:rgb(0,0,0)">)</span><br><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">myProject</span><span style="color:rgb(0,0,0)">.</span><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">targets</span><span style="color:rgb(192,192,192)"> </span><span style="color:rgb(0,0,0)">=</span><span style="color:rgb(192,192,192)"> </span><span style="color:rgb(0,0,0)">[</span><span style="color:rgb(192,192,192)"> </span><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">cmake</span><span style="color:rgb(0,0,0)">.</span><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">SharedLibrary</span><span style="color:rgb(0,0,0)">(</span><span style="color:rgb(0,128,0)">"testLibrary"</span><span style="color:rgb(0,0,0)">,</span><span style="color:rgb(192,192,192)"> </span><span style="color:rgb(0,0,0)">[</span><span style="color:rgb(0,128,0)">"lib.cxx"</span><span style="color:rgb(0,0,0)">])</span><span style="color:rgb(192,192,192)"> </span><span style="color:rgb(0,0,0)">]</span><br><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">cmake</span><span style="color:rgb(0,0,0)">.</span><span style="font-family:monospace;font-size:9pt;color:rgb(0,0,0)">generate</span><span style="color:rgb(0,0,0)">()</span></blockquote>











<pre style="margin-top:0px;margin-bottom:0px"><br></pre>Thanks a lot for your comments, I'm happy to see this was not just a dumb idea, and that others have thought about it.</div><div><br></div><div>I'll update with the github as soon as I get it working.</div><div><br></div><div>Best</div><div><div class="h5"><div><br></div><br><div class="gmail_quote"><div dir="ltr">Le lun. 4 janv. 2016 à 01:16, Stephen Kelly <<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Charles Huet wrote:<br>
<br>
> * cmCacheManager::AddCacheEntry was made public, as cmake::Configure<br>
> cannot be used from python (it check for the existence of a CMakeLists.txt<br>
> file, which does not exist in this scenario) and the cache variables it<br>
> sets seem to be necessary.<br>
<br>
Because of the above, I worry that you are basing your work on an old<br>
version of CMake. As of April 2015 cmState is used as the interface to the<br>
cache.<br>
<br>
 <a href="https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13" rel="noreferrer" target="_blank">https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13</a><br>
<br>
Also note that the C++ interfaces in CMake are not stable. In the last year<br>
they have been changed utterly and that will continue to happen without<br>
notice. I'm sure you know this, but I thought I'd say it anyway.<br>
<br>
> I will try to make a layer of abstraction on top of the python bindings<br>
> before publishing this work on github, in order to show the syntactic<br>
> sugar python can provide, but I will publish this before if anybody is<br>
> interested in working on this.<br>
<br>
I would be interested in seeing it.<br>
<br>
> Now, does anyone beside me think this is a good idea ?<br>
<br>
I did something similar some years ago with QML instead of python, so it<br>
sounds interesting to me.<br>
<br>
In fact, one of the reasons for introducing cmState and doing all the<br>
refactoring I did in cmake was to make it possible to cleanly replace the<br>
language, some day.<br>
<br>
My guess is that you are using python to instantiate a cmAddLibraryCommand<br>
and then executing it. I think a better approach would be to leave all the<br>
cm*Command classes behind as they carry a lot of backward compatibility<br>
baggage and policies which a new language shouldn't be burdened with.<br>
<br>
Even much of cmMakefile shouldn't be used by a new language. Instead certain<br>
parts of cmMakefile should be extracted as other classes (cmVariableExpander<br>
which should have the ExpandVariablesInString and ConfigureString stuff,<br>
cmMessenger for the IssueMessage stuff, some other class for the<br>
CompileFeature stuff etc). Then cmMakefile would be just about executing and<br>
scoping the CMake language. A new language would not need that, but would<br>
use the refactored extracted classes.<br>
<br>
So, you would implement new cmPython*Command or whatever which operate on<br>
those classes and cmState. cmState is designed to be a language-agnostic<br>
store of data, like a database of buildsystem state.<br>
<br>
As I said though, this would require further refactoring of the cmake code.<br>
I can provide guidance on how to do that if you are interested in pursuing<br>
that route. It would take some months I think, but be very valuable for many<br>
reasons and long-term cmake features. Another example of the kind of<br>
refactoring I mean is putting target state in cmState and making it<br>
accessible through cmState::Target, similar to how cmState::Directory<br>
currently works.<br>
<br>
Having said all that, Brad favors Lua I believe, and he favors a different<br>
approach (which no one is working on as far as I know) to adding a new<br>
language. So wait to hear from him to know whether it is something that<br>
would be upstreamable.<br>
<br>
I would prefer an approach similar to what I described above, which is close<br>
to what you are doing, so as a proof of concept I would like to see your<br>
work.<br>
<br>
I would guide/support you in refactoring cmake as needed. The refactoring<br>
part would definitely be upstreamable. I would very much like to see a proof<br>
of concept alternative language even if that wasn't upstreamed. It would<br>
prove that another language is possible, and that's one of the steps to<br>
replacing the current cmake language I think.<br>
<br>
Thanks,<br>
<br>
Steve.<br>
<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>
<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>