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