[cmake-developers] cmake daemon mode protocol

Tobias Hunger tobias.hunger at gmail.com
Sat Jan 16 08:28:03 EST 2016


Hi Stephen,

I think what I suggested so far is covered by the first way of
interaction covered in
http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411 .

I am just proposing something that is convenient for me to use.

On Sat, Jan 16, 2016 at 12:26 PM, Stephen Kelly <steveire at gmail.com> 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.

I am thinking about the simplest possible use-case I can think of
right now: User gets sources from a project somewhere and wants to
build those.

What is entirely unclear to me with your current implementation is how
do I get from "sources are checked out in $DIR" to "I have a $BUILD
that I can use to start the daemon"?

Then I also do not see how I can support a user switching between two
build directories. Do I need to close down one daemon and start
another?

> 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

That list is so full of cmake internals that it is basically
meaningless to me. Sorry.

>>> 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.

"task" is just some Id to identify what the daemon is currently doing.
"state" is just some indication of whether the daemon thinks it is
busy with something or not. In "idle" state it should accept more
requests, in "busy" state it will just queue them or maybe even ignore
them.

>> 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.

So let's forget about all the interactive stuff for now. That is IMHO
step 2, after the basic protocol is validated by implementing bare
bones project information:-)

>> 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.

I agree and do not expect anything different.

Basic protocol functionality from my point of view needs to include:
* Being able to detect the daemon or IDE becoming unresponsive
* Being able to find which responses are the result of which requests
* Being able to reliably find what kind of object I got as request or response

>From the point of view of an IDE: Being able to have progress
information is not a high level detail to be filled in later.

Best Regards,
Tobias


More information about the cmake-developers mailing list