Hi, Because of the above, I worry that you are basing your work on an old > version of CMake. As of April 2015 cmState is used as the interface to the > cache.
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. I did something similar some years ago with QML instead of python, so it > sounds interesting to me. 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. My guess is that you are using python to instantiate a cmAddLibraryCommand > and then executing it. 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. Even much of cmMakefile shouldn't be used by a new language. Instead certain > parts of cmMakefile should be extracted as other classes > (cmVariableExpander > which should have the ExpandVariablesInString and ConfigureString stuff, > cmMessenger for the IssueMessage stuff, some other class for the > CompileFeature stuff etc). Then cmMakefile would be just about executing > and > scoping the CMake language. A new language would not need that, but would > use the refactored extracted classes. Ah, this is very interesting, thanks. 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 ? SWIG would allow for Lua bindings as easily, but I don't think having multiple languages would be a good idea. 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. I would guide/support you in refactoring cmake as needed. The refactoring > part would definitely be upstreamable. I would very much like to see a > proof > of concept alternative language even if that wasn't upstreamed. It would > prove that another language is possible, and that's one of the steps to > replacing the current cmake language I think. I will need to work on it to make it work again with master, but I'll try and do this soon. Here is what my test POC looked like for generating a simple shared library: #!/usr/bin/env python > # -*- coding: utf-8 -*- > import cmake > cmake.init("Ninja", "/media/dev/src/cmaketest", > "/media/dev/build/cmaketest") > myProject = cmake.Project("MyTestProject") > myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ] > cmake.generate() 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. I'll update with the github as soon as I get it working. Best Le lun. 4 janv. 2016 à 01:16, Stephen Kelly <steve...@gmail.com> a écrit : > Charles Huet wrote: > > > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure > > cannot be used from python (it check for the existence of a > CMakeLists.txt > > file, which does not exist in this scenario) and the cache variables it > > sets seem to be necessary. > > Because of the above, I worry that you are basing your work on an old > version of CMake. As of April 2015 cmState is used as the interface to the > cache. > > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13 > > Also note that the C++ interfaces in CMake are not stable. In the last year > they have been changed utterly and that will continue to happen without > notice. I'm sure you know this, but I thought I'd say it anyway. > > > I will try to make a layer of abstraction on top of the python bindings > > before publishing this work on github, in order to show the syntactic > > sugar python can provide, but I will publish this before if anybody is > > interested in working on this. > > I would be interested in seeing it. > > > Now, does anyone beside me think this is a good idea ? > > I did something similar some years ago with QML instead of python, so it > sounds interesting to me. > > In fact, one of the reasons for introducing cmState and doing all the > refactoring I did in cmake was to make it possible to cleanly replace the > language, some day. > > My guess is that you are using python to instantiate a cmAddLibraryCommand > and then executing it. I think a better approach would be to leave all the > cm*Command classes behind as they carry a lot of backward compatibility > baggage and policies which a new language shouldn't be burdened with. > > Even much of cmMakefile shouldn't be used by a new language. Instead > certain > parts of cmMakefile should be extracted as other classes > (cmVariableExpander > which should have the ExpandVariablesInString and ConfigureString stuff, > cmMessenger for the IssueMessage stuff, some other class for the > CompileFeature stuff etc). Then cmMakefile would be just about executing > and > scoping the CMake language. A new language would not need that, but would > use the refactored extracted classes. > > So, you would implement new cmPython*Command or whatever which operate on > those classes and cmState. cmState is designed to be a language-agnostic > store of data, like a database of buildsystem state. > > As I said though, this would require further refactoring of the cmake code. > I can provide guidance on how to do that if you are interested in pursuing > that route. It would take some months I think, but be very valuable for > many > reasons and long-term cmake features. Another example of the kind of > refactoring I mean is putting target state in cmState and making it > accessible through cmState::Target, similar to how cmState::Directory > currently works. > > 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. > > I would prefer an approach similar to what I described above, which is > close > to what you are doing, so as a proof of concept I would like to see your > work. > > I would guide/support you in refactoring cmake as needed. The refactoring > part would definitely be upstreamable. I would very much like to see a > proof > of concept alternative language even if that wasn't upstreamed. It would > prove that another language is possible, and that's one of the steps to > replacing the current cmake language I think. > > 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 >
-- 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