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

[Tamás Kenéz]

Charles,

I'd like to comment on a minor issue:

CMakeLists.txt files don't specify user-specific data like source and build
dirs (for a reason) yet your POC listfile contains this line:

    cmake.init("Ninja", "/media/dev/src/cmaketest",
"/media/dev/build/cmaketest")

which sets the source and build directories. Is this some temporary
solution for the POC only?

Tamas

On Mon, Jan 4, 2016 at 8:41 AM, Charles Huet <charles.huet at gmail.com> wrote:

> 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
>>
>
> --
>
> 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/05135915/attachment-0001.html>