On 06/23/2016 05:19 PM, Tobias Hunger wrote: > I'll create a task to rename it to "server" then.
Sounds good. >> Would each type of query have a known type of response? > > It has a type: "reply" (or "error"). I so far use the inReplyTo field to > specify what the request a reply refers to. Stephen thinks that is not > necessary as there is always one request in flight and the client can just > figure things out without additional information. Okay. If the field makes debugging or other use cases easier I see no reason not to include it. >> Also, doesn't the cookie allow the query/response pairs to be matched? > > In theory yes. But a protocol should work without having to reply on cookies. Yes, I see. > The header currently is the type, inReplyTo and the cookie. I did not see > the need to separate those. Okay. This may be easier to review in context when the time comes. >> Currently cmake-gui supports switching generators, build trees, etc., so >> there is some precedent for such switching within a single process. If >> we have (re-)initialization bugs they should simply be fixed. > > So you think we should keep that? No. See response in another branch of this thread. >> I'm not sure we have that information. IIRC CMake only adds settings to the >> generated build system to tell the tools where to put the .pdb and what to >> call it if it happens to be created. > > I think CMake should know what is generated and should not leave decisions > like that up to generators. Yes, but that will take some additional investigation and work to achieve. CMake will have to be taught more about which tools/platforms actually produce the .pdb files. They are not first-class artifacts in CMake's model right now. > I like "cmakeInputs" Sounds good. Thanks, -Brad -- 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
