He everybody, sorry, I am currently not making the progress I want. Qt Creator has feature freeze coming up and I need to push some patches and fix some bugs.
Brad, Daniel: You both mentioned wanting to use libuv. Is somebody already looking into merging this into cmake? So far I just link against the library and am done with it... Stephen said 3rd party libraries would need to be checked into cmake and that scripts exist to keep these libraries up-to-date. What can I do to help getting this library available to all cmake users (so that I can further shrink my patch set;-)? On Mon, Jun 27, 2016 at 5:03 PM, Brad King <brad.k...@kitware.com> wrote: > 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. Good, I'll keep inReplyTo for now. >>> 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. Ok, I'll keep things the way they are for now then. Changing that should not be too hard anyway. >>> 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. OK, going for the command line switching model then. >>> 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 currently list the PDB files in the artifacts (if there is a .lib file). I'll keep that for the time being. Best Regards, 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
