[cmake-developers] Supporting monolithic and efficient CMake + Ninja builds for LLVM developers

Brad King brad.king at kitware.com
Mon Aug 10 10:56:30 EDT 2015


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



More information about the cmake-developers mailing list