[cmake-developers] [Qt-creator] CMake daemon for user tools
steveire at gmail.com
Tue Jan 12 15:24:24 EST 2016
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
> The generate-json-description approach remains a valid alternative.
> Aleix's work on it got pretty far before Stephen proposed the daemon
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++
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
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?
More information about the cmake-developers