[cmake-developers] CMake daemon for user tools

[Brad King]

On 01/11/2016 09:59 AM, Aleix Pol wrote:
> I'm unsure of the feasibility of the project though. Getting any
> changes in cmake takes forever (this initiative started almost 2 years
> ago already and it hasn't had any impact yet)

This particular change will establish a much wider contract between
CMake and IDEs than we have now, and it has never been clear what
the best approach should be.  That is why this change is taking so
long.  It was unfortunate that your (Aleix's) first iteration I
reviewed and guided last year got so far and took you so much of your
time before others came forward with criticisms of the approach, but
I think in the long run we can do something better.

> and we still need to proof the approach and make sure it has mechanisms
> to provide retro-compatibility. At least to some extent.
> 
> At the very least, I'd like to see cmake maintainers committing to the
> initiative, to make sure I don't waste more of my time.

Stephen's cmState refactoring has been a fantastic cleanup and improvement
of the organization of CMake's implementation.  It is a major step toward
separating the configuration and generation steps and will be useful for
many future directions of CMake.

However, after needing to make fixes between 3.4.0 and 3.4.1 like these:

 cmState: Avoid accumulating policy stack storage for short-lived scopes
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f21dc4a8

 cmState: Avoid accumulating snapshot storage for short-lived scopes
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f860ebb

I'm concerned that the memory usage of a daemon implementing the proposed
capabilities may be too large to be practical (at least without a major
redesign of certain structures that tend to duplicate substrings, or
some kind of out-of-core approach).

The proposed daemon could help IDEs integrate with the CMake language
without re-implementing it, but we may not need such heavy infrastructure
for IDEs just to list targets and sources and allow users to edit them.
The current need for it is due to the fact that the build specification
is in an imperative language instead of a declarative format.  I think
a better approach forward is that discussed in this thread:

 CMake alternative language
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15374

Over there I propose moving the majority of the specification into a
stateless format that IDEs could more easily load, edit, and save.

While the daemon proposed here may have value, I think we should first
resolve discussion of the approach proposed in the other thread.

-Brad