Hi Stephen,
Am 15.01.2016 00:38 schrieb "Stephen Kelly" <steve...@gmail.com>:
> > * Start daemon-mode without any additional parameters
> >
> > * Daemon responds with "
> > {
> > "type": "handShake",
> > "version": "3.5.x",
> > "supportedProtocols": "3.5"
> > }
>
> As you discovered, the cmake binary might not even support the daemon mode
> at all.
That is really straight forward to detect: It will send malformed JSON on
stdout if daemon-mode is unsupported:-) The error message you get is not
JSON and definitely on of type handShake.
> I think what you are really asking for is 'the capabilities of the cmake
> binary'. In that sense, you might also want to know what generators are
> available, whether daemon mode is available (and with which protocol
> versions) etc.
>
> The issue at
>
> http://public.kitware.com/Bug/view.php?id=15462
>
> proposes to dump that information to stdout with a different -E command.
I do not really see the need for that.
Daemon-mode is easy to detect by the reply to the attempt to start it.
Everything else I expect to extract from within daemon mode.
> >
> > * Client Handshake:
> > {
> > "type": "handshake",
> > "requestProtocolVersion": "3.5"
> > }
> >
> > * Daemon:
> > {
> > "type:"handshake",
> > "protocolVersion": "3.5"
> > }
>
> Something like this is possible too. It's not far off what is already done
> in the branch.
I know, that is what this is based on after all. All I want is to be able
to start daemon-mode without having a builddir that is already associated
with a sourcedir.
> > At this point the normal operation should be possible.
> >
> > * Client:
> > {
> > "type": "setProjectInformation",
> > "sourceDirectory": "/some/path",
> > "cookie": "1"
> > }
> >
> > Being able to set the source directory is important so that a fresh
> > checkout can be configured. There is no build directory available at
> > that time...
>
> I understand the desire to inspect a cmake project without asking the user
> to specify a build dir,
You can safely read the CMakelists at this point, give syntax errors, maybe
even extract basic information like project name at this point.
> but cmake has to write build files somewhere in
> order to test the compiler etc.
If this works with a temporary build directory, then these files probably
do not need to litter the build directory in the first place:-)
> 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.
Hey, the idea is to improve on the current situation, not to perpetuate the
workarounds.
And how do I associate an empty directory as a builddir to a sourcedir?
How can I switch between builds when the daemon-mode is set up to work with
one builddir? Do I have to close it down and start a new daemon for the
next build?
That would be suboptimal, as all the built-in dependent state of the
project would need to get regenerated by the new daemon. Associating a
daemon with a sourcedir and being able to switch builddir would be nicer.
> 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.
The daemon is not need to persist its state to disk all the time like
command-based cmake currently needs to.
> > * Daemon should do progress handling while reading the CMakeLists.txt
> > or whatever it does:
> > { "type": "progress", "state": "busy", "task": "someId",
> > "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" }
> >
> > * Daemon sends occasional:
> > { "type": "progress", "task": "someId", progressTotal: 25,
> > progressCurrent: 12, "cookie": "1" }
>
> Yes. CMake can provide approximate values of how complete the configure
step
> is. See cmGlobalGenerator::AddMakefile. That could be exposed to the
daemon
> 'somehow', such as by defining some virtual callback interface.
>
> 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.
> > * Finally Daemon responds sends data as that is available now.
> > {
> > "type": "projectInformation",
> > "sourceDirectory": "/some/path",
> > "buildDirectory": "",
> > "projectName": "SomeProject",
> > "cookie": "1"
> > }
>
> At this point in your proposal, cmake has run the configure step in a
> temporary directory, right?
I am currently arguing with complete ignorance of how cmake works
internally:-) This is just what I think makes the most sense from an IDE
perspective.
> So it would be
>
> "buildDirectory": "/tmp/foo/bar"
>
> right?
No.
The daemon should be associated with a sourcedir, not a builddir. At this
point there should not be a builddir yet!
I think it makes sense to get the built-in dependent information first,
before having a builddir set and then proceeding to generate the
build-dependent information.
> > * Client:
> > {
> > "type": "setProjectInformation",
> > "buildDirectory": "/some/other/path",
> > "cookie": "2"
> > }
>
> As this sets a new build directory, cmake will have to run the configure
> step from scratch in this new location.
>
> > * Daemon does progress indication as above...
> >
> > * Daemon responds with project info:
> > {
> > "type": "progressInformation",
> > "sourceDirectory": "/some/path",
> > "buildDirectory": "/some/other/path",
> > "projectName": "SomeProject",
> > "cookie": "2"
> > }
>
> I must admit I'm not seduced by this idea as it seems to be that it should
> be easy for an IDE to build in a temporary dir itself.
>
> However, I think it makes sense to design the protocol to handle
specifying
> either a sourceDir or a buildDir (or both if from scratch). Starting
daemon
> mode without arguments as you suggest could work (though we would have to
> see how that affects the protocol). Or with a different argument (eg
>
> cmake -E daemon buildDir
> cmake -E daemon_source sourceDir
>
> ) could work. I am also just brainstorming ideas, not proscribing
anything.
You are a prisoner of the current implementation:-)
> > We might also want a "ping"/"pong" to detect if the daemon is still
> > responding.
>
> Yes, I had the same thought. I also considered self-terminating the daemon
> if there is no message on the wire for N seconds, effectively requiring
the
> IDE to ping every N seconds if it is not doing anything else. I
considered
> this because otherwise the IDE might crash and leave zombie cmake daemons
> running, but I didn't investigate that possibility.
True. But I am actually more concerned with the daemon freezing:-)
> > That would require the daemon to be able to handle
> > multiple requests to be in flight... not sure that this is worth it.
>
> Yes, adding a multi-threading requirement to the daemon might make some
> implementation more difficult. I've seen some videos on designs for things
> like that though, and I am interested in trying them out.
>
> > But if we can not do that, then we need to provide constant progress
> > information, which is also not great:-)
>
> The good news is that after the initial configure and compute steps are
> finished (where progress makes sense anyway I think), all other requests
are
> 'very fast'.
So "cmake --build" is out of scope for the daemon?
> > Not sure about the need for cookies (text set by the client and
> > repeated by the server in all its replies to that request). I do think
> > having them makes sense, even when only one request can be active at
> > any time: They make it so much easier to sanity-check communication.
>
> Yes, I considered something like that in the protocol too. I didn't add
any
> because I didn't encounter the need yet in the parts of the protocol I
> implemented and the proof-of-concept tooling I made, so I deferred that
part
> of the design space until a time when more requirements are known.
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:-)
> > Consistently having a "type" in all messages going back and forth is
> > probably a good idea for the same reason as having cookies.
>
> Yep.
Good!
> Thanks for this useful feedback!
You are welcome.
Tobias
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
