[cmake-developers] cmake daemon mode protocol

[Stephen Kelly]

Tobias Hunger wrote:

>> For this case, I suggest that if the user tries to 'open the source
>> directory', you would use QTemporaryDir to build in a temporary location
> and
>> run the daemon there. I believe clion does something equivalent to that.
>> Is that viable? I suppose you are suggesting that cmake do that instead
>> of leaving it for clients to do?
> 
> It is doable. I just do not see why this should be necessary.

I'm aiming to first design as much as possible of a 'minimal viable 
protocol' as a first step. Given the above I think your ideas of running the 
daemon with no build dir are not 'minimal' and I'm convinced they're not 
viable. 

Someone would have to prototype the ideas, but I don't think that's a good 
use of time or energy right now (mostly because I think they're not viable).

I recommend focussing on the tasks in my OP:

 http://thread.gmane.org/gmane.comp.lib.qt.creator/11794

>> Richer information about some semantics like 'task' and 'busy state'
>> could also be provided in a similar way I expect, assuming those could be
> defined.
> 
> This is some basic functionality that we should get right soon, as this
> can influence how long-running tasks need to be designed.

Yes. Perhaps you can expand on what 'tasks' and 'busy state' you have in 
mind. Particularly if you can relate them to what is already in my github 
branch.

> So "cmake --build" is out of scope for the daemon?

I listed three ways cmake and an IDE could interface here:

 http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411

'triggering the build' would be a fourth. I don't think it needs to be part 
of the initial discussion of the design. 

Let's try to keep scope small so that we can get on common ground.

> That is why I brought up progress information so early: They make things
> complicated by there suddenly being several responses to a request and you
> need a way to identify those. At that point simpler solutions tend to blow
> up:-)

Yes.

BTW: I don't expect to get any part of the design of the protocol 'right' on 
the first iteration. I think we need to start everything that will need to 
be in the protocol, then iterate. Start high level ignoring details, and 
fill in the details as we iterate and can encode needs in unit tests.

Thanks,

Steve.