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