Thoes files are used to build Android toolchain. D32816 makes it possible to build runtimes for targets.
Details
Diff Detail
- Build Status
Buildable 8536 Build 8536: arc lint + arc unit
Event Timeline
@jroelofs we are not building builtins currently but we are planning to do so. I just added some basic configurations for builtins.
cmake/caches/Android-stage2.cmake | ||
---|---|---|
38 | No. Absolutely not. Whether or not the bits of the toolchain that run on the host have assertions should be *completely* independent of whether the target bits do or don't. Do not conflate the host with the target. |
cmake/caches/Android-stage2.cmake | ||
---|---|---|
38 | Maybe I wasn't clear. I suggest that we don't set RUNTIMES_${target}_LLVM_ENABLE_ASSERTIONS to ON here and rather initialize it based on another flag. I was incorrect to suggest we reuse LLVM_ENABLE_ASSERTIONS. We should rather have something like ANDROID_RUNTIMES_ENABLE_ASSERTIONS. The motivation is to reduce the number of additional flags/switches, under the assumption that assert-enabled or assert-disabled builds of the runtimes are generated simultaneously. To generate assert-enabled builds, the invocation would be: $ cmake ... -DANDROID_RUNTIMES_ENABLE_ASSERTIONS=ON instead of $ cmake ... -DRUNTIMES_armv7-linux-android_LLVM_ENABLE_ASSERTIONS=ON -DRUNTIMES-aarch64-linux-android_LLVM_ENABLE_ASSERTIONS=ON ... If I understand CMake correctly, we can still enable assertions only for a particular target by: $ cmake ... -DANDROID_RUNTIMES_ENABLE_ASSERTIONS=OFF -DRUNTIMES-aarch64-linux-android_LLVM_ENABLE_ASSERTIONS=ON |
cmake/caches/Android-stage2.cmake | ||
---|---|---|
38 | Yeah, collecting them under a common default seems fine. The only thing I was objecting to was having that default be tied to the settings of the host part of the build. |
Add STAGE2_ prefix to pass stage2 variables. Add ANDROID_RUNTIMES_BUILD_TYPE, ANDROID_RUNTIMES_ENABLE_ASSERTIONS, and ANDROID_BUILTINS_BUILD_TYPE.
Same comment as ASSERTIONS below.