On 06/06/2016 11:39 AM, Tobias Hunger wrote: > This is why I started working on making Stephen's code merge-able and more > robust. I will also volunteer to help maintain this code going forward.
Great, thanks! Hopefully I will have time to look at this in more detail soon. For now here are a few responses. > So far I copied over the daemon itself from Stephen. On top of that I added > some > nicer request/respond handling code (you get pretty similar messages from > everything, you can set a cookie in a request, which will be handed back on > response/error, there is a defined way to report a response or an error > condition), progress reporting (directly hooked up to cmake), and a couple of > basic commands to get started (reset, etc.), and some future-proofing by being > able to support several versions of the daemon protocol. Good. I like the use of libuv. I've been meaning to add the infrastructure to make libuv available as something we can use in CMake upstream so that we can port process execution away from KWSys and to libuv. The daemon mode will be a great client for libuv too. > A big chunk of Stephen's work has not even landed in my branch yet. Since > cmake > reformated all the source in the meantime it is a bit tedious to apply patches > from his tree and I have simply not yet needed the changes as I did not > venture > where he went yet. See commit v3.6.0-rc1~54^2~2 (82df6deaaf). Its commit message explains how to rebase across the style transition. If you rebase the original "cmake-daemon" branch on that then we can rewrite the style to make cherry-picking later easier. > At this time I think I will need to duplicate a chunk of code from one of the > generators to find the flags. Is that really necessary? If so: Which generator > should I copy the code from? We should be able to refactor things to share the flags computation. Methods like cmLocalGenerator::GetTargetFlags cmLocalGenerator::GetIncludeDirectories are meant to be used across multiple generators. Due to historical evolution in generator design not everything has been refactored to cleanly share such infrastructure across all generators. Stephen made a lot of progress on that front, but there is still a way to go IIRC. -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
