On Thu, Jun 23, 2016 at 2:27 PM, Tobias Hunger <tobias.hun...@qt.io> wrote: > * We both think it only makes sense to merge the infrastructure part into > cmake (if it passes review first of course) once we have some > functionality > that is genuinely useful. So we want to aim at having the infrastructure > and the codemodel merged in one go.
Please think about adding libuv earlier. As Brad wrote before, libuv could replace some #ifdef code that we currently have (process handling, file operations). I am currently refactoring the code around the cmOutputConverter and I would like to introduce a cmPath class (I will write more about that later, but I can already say that libuv might come handy for some functionality). > 2.7 cache (report contents of CMakeCache.txt file) > > * Review by other potential users would be appreciated, but no obvious > problems seen. Is this needed? If the CMakeCache.txt file continues to be written, clients could just parse that file. If clients want to make changes (ie. cache editors), they can rewrite the file. Is that a problem? I assume it is, because CMake needs to reconfigure when it rereads it. In that case, the server should provide a way to report the contents, but also ways to modify it. Cheers, Daniel PS: Next meeting in a Biergarten in Munich? -- 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
