MantisBT - CMake
View Issue Details
0015679CMakeCMakepublic2015-08-04 12:452016-01-04 11:52
Chris 
 
normalfeatureN/A
closedsuspended 
Apple MacOS X10.10.4
CMake 3.3 
 
0015679: ExternalProject with Ninja generator should import sub-project's build.ninja into the parent project
Ninja's scheduling works best if it has a full picture of what you're building. Doing that in projects that extensively use ExternalProject can be tricky. To make this work I believe CMake needs to do 3 things that it doesn't do today.

(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.
This request is coming out of the LLVM developer community. As we're moving more actively to CMake we are leveraging ExternalProject more and more for generating cross-compiled targets, bootstrapping the compiler and generating test targets. We believe these improvements to ExternalProject will make for a better developer experience on our end.

Thanks,
-Chris
No tags attached.
Issue History
2015-08-04 12:45ChrisNew Issue
2015-08-04 12:57Chandler CarruthNote Added: 0039230
2015-08-05 10:55Brad KingNote Added: 0039241
2015-08-05 10:55Brad KingStatusnew => resolved
2015-08-05 10:55Brad KingResolutionopen => suspended
2016-01-04 11:52Robert MaynardNote Added: 0040129
2016-01-04 11:52Robert MaynardStatusresolved => closed

Notes
(0039230)
Chandler Carruth   
2015-08-04 12:57   
Just wanted to say that this would be truly amazing for us when working on LLVM and related projects. I'm really hoping it can happen.
(0039241)
Brad King   
2015-08-05 10:55   
I'd like to help LLVM achieve a more monolithic and efficient build system with CMake and Ninja. I invite you to come to our developer's list to discuss possible approaches.

However, I do not think ExternalProject is a good fit for this. Its intended purpose is to isolate an external project builds from each other and from that of the encompassing project. Also the semantics defined by ExternalProject mean that the other projects may not even yet have a source tree available at the time the outer build system is generated. This makes generating a single monolithic build system across multiple ExternalProject uses ill-defined.
(0040129)
Robert Maynard   
2016-01-04 11:52   
Closing resolved issues that have not been updated in more than 4 months.