On 08/07/2015 07:38 PM, Stephen Kelly wrote: > Chris Bieneman wrote: >> One big things I'm working on is improving the way we build our runtime >> libraries. These libraries are built for the targets that the compiler >> supports generating code for, so they can use different architectures, >> headers, and libraries than are used to build the compiler itself. CMake >> does a great job of finding libraries and constructing the compiler >> commands, and we want to leverage that instead of re-implementing it. > > Right. You would need something like what this bug report tracks: > > http://public.kitware.com/Bug/view.php?id=14539
That wishlist item is pretty far-fetched currently and IMO would be a monumental effort to achieve. Also, this part is different: On 08/05/2015 03:56 PM, Chris Bieneman wrote: > need to use the just-built clang to build the runtime libraries [snip] > Doing this would allow ExternalProjects that are CMake to generate > targets that could be imported back into the parent ninja build. That proposal involves having a single build tree that at first only knows how to build clang. Once it is built the first time then additional configuration is added to enable builds with the just-built clang as the compiler. Ideally after that there would be a single monolithic Ninja build process that can update everything at once (rebuild the compiler and the rebuild everything built with that compiler). One possible approach is to somehow include the secondary build.ninja file(s) in the primary one. I'm not sure whether this ideal is achievable. Even if the seconary build files were included by the primary ones, each time the compiler rebuilds then CMake would have to be re-run to regenerate the secondary build files. At that point Ninja would have to stop, reload the build files, and start over. Effectively this would be a really complicated way of achieving the build performance that we already have with ExternalProject now. So, I don't think it will be beneficial to try to combine the build rules for clang and the build rules for everything that needs to be built with the just-built clang to fit under a single monolithic Ninja build file. At most we could try to get the latter part to work as a single build system. Then a full rebuild would be two steps (build clang, and built everything with the just-built clang) instead of 1+N steps, where N is the number of target architectures. I think configuring for multiple toolchains/architectures in a single CMake execution (as proposed in #14539 above) is a large effort, but a special-case solution for Ninja may be more realistic. -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
