Hello Bard,

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.

Kind regards,

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
> loaded.
> 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
> language
> that drives the configuration process because any such language could still
> have a command/step that loads the declarative part.
> -Brad

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