[cmake-developers] [Discussion] Add python support for CMakeLists

[Shmuel H,]

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.king at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/7447158e/attachment-0001.html>