[build] Link the Swift resource directory against the headers from a prebuilt clang, if building with one #40707
Conversation
…prebuilt clang, if building with one
|
@swift-ci please test |
|
Build failed |
|
macOS failure: |
|
Build failed |
|
Linux CI failure was unrelated, as the CI was simply broken at the time with a prior CI run of another pull failing with the same error, and the macOS CI failure appears spurious, probably flaky tests as this pull doesn't affect the iphonesimulator. |
|
I've seen the linux load commands test failing on some other unrelated PRs as well. |
|
I think the CI is working again now. |
|
@swift-ci please test |
|
Build failed |
|
Linux CI passed, macOS CI flaked on some watchsimulator tests this time. |
|
The macOS failure should have been fixed here: #40760 |
|
@swift-ci please test macOS |
|
Passed CI, ready to merge. |
|
There you go |
When building with a prebuilt Clang, the changes introduced in #40707 supposed that the toolchain was in its final path. When building in stages (first the toolchain, then the standard library), the toolchain might not be in the final path, and the created symlink will point to a machine-local path that does not make sense. The changes introduced should not modify the existing behaviour introduced by #40707, but should allow customizing the final installation target using the CMake cached variable for those setups that need the flexibility.
If building the stdlib with a prebuilt clang, link against its headers rather than assuming they are installed in the Swift toolchain. This is particularly useful when building standalone, cross-compiled SDKs, as I've been patching my Android SDKs to do this for years.
@llvm-beanz, you set this symlink directory in #5034 years back, would you review?