[PATCH] D145884: test-release.sh: build projects and runtimes lists with semicolons

[Dimitry Andric via Phabricator via llvm-commits]

dim added a comment.

In D145884#4264777 <https://reviews.llvm.org/D145884#4264777>, @mstorsjo wrote:

> 

...

> In D145884#4262759 <https://reviews.llvm.org/D145884#4262759>, @dim wrote:
>
>> Because `CMAKE_LIBRARY_ARCHITECTURE` isn't set, the `find_library()` calls for e.g. zlib (but also other libraries) fail to search `/usr/lib/x86_64-linux-gnu` (or other ABI specific library paths).
>
> I've seen this issue wrt `CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` before, but I'm wondering how it ends up here in this case. Since we're only setting `CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` while configuring specifically `compiler-rt/lib/builtins`, I presume there's nothing that looks for zlib within that? Or does the runtimes build somehow reuse caches for later stages, so that the builtins stage which didn't detect that part of the architecture, ends up breaking later stages?

`compiler-rt/lib/builtins/CMakeLists.txt` includes `compiler-rt/cmake/Modules/CompilerRTUtils.cmake`, then it calls `load_llvm_config()` (a helper function from `CompilertRTUtils`). `load_llvm_config()` figures out the path to `llvm/cmake`, and as far I understand, loads all kinds of settings from there, including paths to llvm headers, libraries, etc. As part of this, it clearly also descends into the "finding required libraries" parts, as it searches for terminfo, zlib, libxml2, etc.

However, when building the runtimes, it starts from the top-level `runtimes/CMakeLists.txt`, so it doesn't seem to follow this logic.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145884/new/

https://reviews.llvm.org/D145884