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 harder? 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, Shmuel. 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: 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
