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

[Chris Bieneman]

(resending now that I’ve subscribed to cmake-developers)

Hello CMake-Developers,

I’m a contributor to the LLVM project working on improving our CMake-based build process, and I had a request I wanted to discuss with your community.

This is related to a feature request I filed (http://public.kitware.com/Bug/view.php?id=15679 <http://public.kitware.com/Bug/view.php?id=15679>), and one of the efforts I’ve been driving in the LLVM community (http://lists.llvm.org/pipermail/llvm-dev/2015-July/088751.html <http://lists.llvm.org/pipermail/llvm-dev/2015-July/088751.html>).

The complication for us is that because we’re building a compiler, and we can be targeting multiple operating systems and architectures within the same build, we want to be able to leverage CMake’s ability to detect the toolchain and target capabilities, which means invoking CMake multiple times.

One of our common uses is building clang. When we build clang it is built with the ability to target a set of architectures. We then need to use the just-built clang to build the runtime libraries for each of the supported targets (which may not match the host operating system or architecture).

Today we do this in a pretty horrible manner by circumventing CMake’s built-in checks and writing custom rules for compile steps; we’re looking to improve it. One of our big goals is that we eventually want a way to generate a single build.ninja file that can drive a full build (including all the cross-compiled targets). Our idea on how this would work was based on extending the ExternalProject support in CMake.

We specifically are looking for three extensions:

(1) ExternalProject needs to prefix all the rules and targets in the ninja file it generates so that they don't conflict with the parent project's rules or targets
(2) ExternalProject calls to CMake need to be marked as Generator rules in Ninja so that Ninja will re-exec itself after running CMake
(3) ExternalProject needs to generate Ninja includes in the parent project.

Doing this would allow ExternalProjects that are CMake to generate targets that could be imported back into the parent ninja build.

Brad commented in the bug that using ExternalProject probably isn’t the best way to accomplish this, and we’re very open to suggestions.

Thanks,
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150805/4f3d1890/attachment.html>