I'd like to have a discussion about using CMake as a library from python,
and by that I mean not writing CMakeLists.txt files, but python code that
then uses the CMake generators and Find*.cmake in order to leverage both
the power of CMake and Python.

First, a bit of background on the idea itself.

I've used CMake since 2010 in different projects at work, and I love it.
I'm the CMake guy at work, because most of the colleagues cannot be
bothered with it. In fact I highly prefer doing the CMake maintenance
myself, as most of the colleagues do not make any effort in trying to apply
best practices of to factorize the code (which they do with the C++ code).

When talking about CMake, the first reaction most of them have is about the
language itself, because they don't know it, don't like some of the idioms,
and have trouble accomplishing what they want with it.

Nobody argues that CMake is awesome at generating either Visual Studio
solutions or Unix Makefiles or whatever, but the language is a high barrier
of entry.

I have to admit that doing seemingly simple stuff can be a bit confusing in
cmake, e.g. checking if the value of a variable is greater than another.

Thus I thought that using a language that is well-known and has a closer
syntax to what we are used to (not to mention we use python quite a bit for
custom scripts) would greatly ease the maintenance of our buildsystem.

This would allow for a few things that are not straightforward in cmake,
such as functions that return a value.

I prototyped around this idea these last weeks (a few minutes or hours at a
time) and got it in a proof of concept state, where I cant do a add_library
in python.

I think this would be a great step forward for writing buildsystems, as
lots of tasks would be greatly simplified. From the top of my mind:
* reading files
* writing files
* downloading files
* copying files (CMake's copy is not POSIX-compliant, as I learned recently
when copying symbolic links)

Also, the syntax could be made Object-Oriented very easily, as the python
bindings will need a layer of abstraction.

Now, for the technical realisation

My prototype required a few modifications into CMake itself:
* I added cmSystemTools::SetCMakeRoot, as the system root cannot be
determined automatically using the current methods
* cmLinkItem's typedef of std::string was made public because swig has
trouble with it. There may be a better way to solve the problem, but this
was the quickest for a POC
* 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.

A cmake.i swig interface file, and a python file that does the
initialization of CMake, and I have a simple library compiled.

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.

Now, does anyone beside me think this is a good idea ?


Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 

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 

Follow this link to subscribe/unsubscribe:

Reply via email to