build: place executable content into the root of the build #515
Conversation
|
@swift-ci please test |
| @@ -19,6 +19,12 @@ set(CMAKE_CXX_STANDARD 11) | |||
|
|
|||
| set(CMAKE_C_VISIBILITY_PRESET hidden) | |||
|
|
|||
| # NOTE(compnerd) this is a horrible workaround for Windows to ensure that the | |||
There was a problem hiding this comment.
Can you please do this for Windows only, and not for other platforms? I don't think having an identical directory layout between platforms is necessary; each have their own conventions which we should follow.
There was a problem hiding this comment.
This is the same thing that LLVM does on all the platforms, as does the Swift project. What do we gain by doing it as a special case here? Furthermore, this is the build tree only, so having the identical directory layout is necessary to keep the overall packaging rules identical. (e.g. copying of files).
There was a problem hiding this comment.
Ah, right, this is for the build layout, not the installed layout.
Adjust the output location of the generated executable content to the root of the build tree. This is needed primarily on Windows where there is no concept of a RPATH, and the current directory is scanned for the dependent libraries.
compnerd
force-pushed
the
output-directory
branch
from
fb13240 to
e47283c
Compare
|
Please test with following PRs: @swift-ci please test |
|
Please test with following PRs: |
|
Please test with following PRs: @swift-ci please test |
|
Please test with following PRs: @swift-ci please test |
1 similar comment
|
Please test with following PRs: @swift-ci please test |
| @@ -19,6 +19,12 @@ set(CMAKE_CXX_STANDARD 11) | |||
|
|
|||
| set(CMAKE_C_VISIBILITY_PRESET hidden) | |||
|
|
|||
| # NOTE(compnerd) this is a horrible workaround for Windows to ensure that the | |||
There was a problem hiding this comment.
Ah, right, this is for the build layout, not the installed layout.
|
@ktopley-apple - okay to merge? |
|
Yes, done :-) |
|
Unfortunately, @jakepetroules was right, as there are Swift tests that look for libdispatch.so and other files under the old build layout and are now disabled on the linux CI as a result of this pull, specifically all tests for the libdispatch and tsan_runtime features. I confirmed by examining the build log for this commit and comparing with the previous commit's build log: note that libdispatch and tsan_runtime are missing from the available features for lit.py before the Swift testsuite is run only in the first linked log. This can be verified further through tests like Sanitizers/tsan or stdlib/DispatchData going from passing to unsupported after this pull. I ran into this because I noticed that these tests were being run in prior Swift test logs I had run natively on Android, but were disabled recently, which I tracked down to this pull. |
|
@compnerd or @drodriguez, should I file a bug in the Swift JIRA for this tsan/libdispatch issue with the linux CI, so that enabling those tests again isn't forgotten? Update: Filed. |
The swift-corelibs-libdispatch project had its build directory layout changed [1] which silently deactivated the libdispatch tests on Linux, because we use hard-coded paths to look for the required libdispatch artifacts. This change adapts the paths to the new layout. Thanks to Jordan Rose for noticing and diagnosing this [2]. SR-11568 [2] https://bugs.swift.org/browse/SR-11568 [1] swiftlang/swift-corelibs-libdispatch#515
* Reactivate libdispatch tests on Linux The swift-corelibs-libdispatch project had its build directory layout changed [1] which silently deactivated the libdispatch tests on Linux, because we use hard-coded paths to look for the required libdispatch artifacts. This change adapts the paths to the new layout. Thanks to Jordan Rose for noticing and diagnosing this [2]. SR-11568 [2] https://bugs.swift.org/browse/SR-11568 [1] swiftlang/swift-corelibs-libdispatch#515 * Fix libdispatch Swift module directory
build: place executable content into the root of the build Signed-off-by: Rokhini Prabhu <[email protected]>
Adjust the output location of the generated executable content to the root of
the build tree. This is needed primarily on Windows where there is no concept
of a RPATH, and the current directory is scanned for the dependent libraries.