[Qt-creator] CMake daemon for user tools

[Stephen Kelly]

Hunger Tobias wrote:

> Hi Stephen,
> 
> I registered for the Berlin Meetup already and am looking forward to get
> an update on your progress on the cmake front:-)

Cool, til then!

> Having a file with the important data would have been nice -- at least as
> an intermediary step:-)

As Brad wrote, this is about establishing a very wide contract between cmake 
and user tools. An intermediate step/implementation in master couldn't ever 
be removed, so it wouldn't really be intermediate, and keeping it working 
would tie our hands for the future.

>> I am scheduled to give a talk at FOSDEM about the feature and how user
>> tools can interact with it:
>> 
>> https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code
> 
> Are you aware whether there will there be a recording of the presentation?
> Please keep us updated with a link if there is:-)

I believe it will be recorded. However at FOSDEM I will have only 30 mins, 
and at the meetup I'll have an hour, so you'll likely get more content then 
anyway :).
  
>> However, I can't complete those tasks myself: I don't have
>> relevant experience building IDEs to know how best to design the
>> protocol, what IDE tools really need, how to design a fail-safe parser
>> etc.  Additionally, I think a design which incorporates design ideas
>> and implementation from more than one person will be better in the end.
> 
> About the protocol: Just use something existing? GDB has something, or
> maybe just expect/return JSON or XML? Web services seem to work well with
> such an approach:-)
> 
> <snip>
> 
> I'll take a look at the repo.

Yes, from looking at the repo you may have seen that it is using JSON. The 
question of protocol is about designing a consistent API and structure of 
the data. Also the question of whether the protocol should be stateful or 
stateless comes up. Currently in the repo it is stateless except for the 
initial handshake. I don't know a reason to change that, but maybe there is 
one. 

Thanks,

Steve.