[cmake-developers] [Qt-creator] CMake daemon for user tools

[Stephen Kelly]

Brad King wrote:
>> Alexander goes back to the generator approach we discussed a year ago
>> and explicitly says he won't work on that, so nothing will happen
>> there.
> 
> The generate-json-description approach remains a valid alternative.
> Aleix's work on it got pretty far before Stephen proposed the daemon
> alternative.  

In between I also made a generic-generated-JSON-file-based approach.

> These problems are orthogonal, and your requirements certainly need
> generation-time information regardless of how the build specification
> itself is represented.  

Yes, this is the stuff that the protocol I put on github provides.

> Therefore the discussion here should proceed
> independent of where the alternative language thread goes.

Yes. I count 3 orthogonal ways an IDE and cmake could 'interface':

1) Provide information about translation of sources into objects so that the 
   IDE can understand those sources - eg includes and defines for c++ 
   sources.

2) Provide semantic information about the CMake code, for example to 
   introspect what is defined at what point in the file for debugging 
   purposes, and for code completion purposes.

3) Provide a way for IDEs to *edit* the buildsystem. For example, if an IDE 
   has an 'add class' dialog, or a 'extract class' refactoring action, they 
   need to add a file to a target. 


The first two are what we have mostly discussed in previous threads that I 
linked in the OP.

A generated JSON file in the buildsystem can provide (1), but can not 
provide the other interfaces. 

A well-designed declarative spec could make it easy for an IDE to do (3) but 
can not provide the other interfaces.

A daemon can provide the first two in a high quality way and allows for more 
extensions in the future. As (3) is orthogonal, a daemon and a declarative 
spec for the sources covers all three. 

Even without the declarative spec, the daemon can tell the IDE exactly where 
to put the target_sources() command as an intermediate step (before the 
declarative spec is available), though that's 'ugly' so I didn't list it as 
something 'high quality' that the daemon could provide.
 
> 2.  CMake offers a daemon that IDEs can contact (e.g. via named pipes)
>     to ask for the information.  The contract between CMake and IDEs is
>     a (to-be-designed) protocol (e.g. JSON snippets).  Updating would
>     likely be handled internally by the daemon in response to changes
>     to the CMake input files between requests from the IDE.

Right. If only some/deep/nested/CMakeLists.txt changes, and cmake knows that 
definitions do not escape via PARENT_SCOPE, and cmake knows that the targets 
defined in that file are not additionally modified elsewhere, it only has to 
re-evaluate the cmake code for that file and not for the entire buildsystem.

> Stephen no longer has time to continue his work except to guide others.

I can do development, but it would have to be as part of a collaborative 
effort and collaborative future maintenance. The latter part is the main 
reason I want to encourage fresh developers (and particularly IDE 
developers) into the cmake code to work on this, and to have some ownership 
on the code and design.

> Given the above summaries my reaction is that the daemon approach is
> more elegant and desirable in the long run.  However, it will require
> much more time and resources to implement.  It is not clear how much
> more, or if anyone has such time and resources to offer.

Yes. I'm trying to generate interest in people who are capable of joining 
the effort, and interested in doing so. It is difficult :).
 
> An intermediate solution could be to offer the daemon and protocol
> to IDEs but to implement it internally on top of pre-generated JSON
> files.  

That's even more effort, no?

> The schema of the JSON files would remain a private contract
> between "cmake" and "cmake-daemon".  Then over time the implementation
> of the daemon could be improved by computing things internally on
> demand instead of updating and reading the JSON files, but the public-
> facing protocol would not change.  We just need to make sure that the
> protocol is designed to allow such flexibility.  OTOH this approach
> requires designing both the daemon protocol and the JSON format.

Yes. I don't understand the proposal. Why implement the protocol in terms of 
files generated by cmake, instead of implementing the protocol in terms of 
state in cmake (one less step)? 

> Note that the generated JSON approach is essentially what we've been
> doing with the VS IDE since CMake started, just with a different format.

Yes, but also without providing an interface for (2) and (3) above.

> Many developers use the VS IDE to develop their CMake-built projects,
> and they get IntelliSense for completion.  It has worked well for years.
> Perhaps the argument for the daemon approach puts too much focus on the
> updating case while most developer time is simply spent editing existing
> sources in their IDE.

I don't understand this bit. Can you rephrase?

Thanks,

Steve.