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
I took the time to make it work again, so I pushed it here:
https://github.com/packadal/CMake/tree/cmake-python
The whole branch is ugly as can be, and because I started with an old CMake
and recently rebased, the python abstraction might be bloated already, but
it works in the nominal case, and
Yes, this is POC-only.
I felt too lazy to make an argparse object and properly perform these tasks.
Obviously, the generator and source dir should be arguments.
The build dir should be the execution dir of the script, to mimic CMake
behavior.
This should not be difficult, but as I said I wanted
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
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
Hi,
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
