[cmake-developers] Using CMake as a library from Python

[Stephen Kelly]

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.