First of all, let me show my appreciation for an open source maintainer
that open for changes which is not a obvious.
The problem with a solution that doesn't add another language as a
dependency is that it creates incompatibility and requires installing of
more components in order to achieve a working system (e.g. Install Python,
Install a program that communicates with CMake Server, etc) which creates
the complete opposite of the "almost universal-compatible build system" the
CMake project has been able to achieve until now.
I'm interested in your reason behind the decision not to add Python as a
dependency: is that a licencing problem, a problem specific about Python,
or maybe a general problem with dependencies, which generally make our life
However, for me - a user, a known and well-designed programming language
for CMake would be very helpful. I can't say that for every other user, but
I think it would make their life a lot easier too.
On Thu, Jan 12, 2017 at 4:27 PM, Brad King <brad.k...@kitware.com> wrote:
> On 01/11/2017 04:23 PM, Shmuel H, wrote:
> > a few endless discussions about this topic
> Previous discussions have not ended in a new language being integrated,
> but that does not mean they failed. Several challenges w.r.t. the
> internal architecture were identified. A lot of progress has been made
> in addressing some of those, but there is more work to do. The goal is
> to separate the representation of the build system model that is fed to
> the generators from the current CMake language implementation. Once that
> is done then other approaches/languages can be added to build the model
> instead of using the current language exclusively.
> > My current design is using Python as an extension for the regular
> > CMakeLists.txt files: if there is a CMakeLists.py file, it would be
> We'd rather not introduce Python as a dependency of CMake's distribution,
> even optionally. It may be reasonable to have optional support when Python
> can be found at runtime. However, any such approach would need to avoid
> requiring dynamic loading of plugins into CMake or any kind of stable
> C++ API to be maintained.
> Since previous such discussions we've now had the cmake-server mode
> introduced. It allows programs written in any language to communicate
> with CMake through a JSON protocol. Currently the protocol is very
> minimal and geared toward IDEs that want to get a representation of the
> build system after configuration of a build tree.
> A similar approach could be used to interact with external processes
> during configuration. Such a protocol would allow programs written
> in any language to be used for defining CMake build systems.
> Previous discussions have also identified the value of having a declarative
> specification format. This is largely orthogonal to the procedural
> that drives the configuration process because any such language could still
> have a command/step that loads the declarative part.
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: