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

Charles Huet charles.huet at gmail.com
Mon Jan 4 02:41:47 EST 2016


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 <steveire at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160104/8480c40d/attachment.html>


More information about the cmake-developers mailing list