swift-test doesn't find xctest bundle with swiftbuild #8272
Assignees
Labels
Comments
dschaefer2
added
bug
swift build
|
Interesting. swift-run does find the executable to run. We need to find out why swift-test doesn't use the same technique. |
|
BTW, this is with a simple project created with |
1 task
|
I potential fix is included in #8276 |
|
@bkhouri can you break that out into a separate change? I'd like to review that separate from the rest of 8276. In theory we can fix that now. |
bkhouri
added a commit
to bkhouri/swift-package-manager
that referenced
this issue
Feb 19, 2025
There are a few places that check the BuildSystemProvider.Kind is Xcode to determine the build directory structure. With the upcoming Swift Build integration, which uses the "Xcode path" structure, we would need to update all instances to check the two build system provider kinds. Add an extension on the BuildSystemProvider.Kind that create a boolean variable `useXcodeBuildSystemPath`, which determines whether the build system should use the xcode path structure or not. In addition, update the code that requires a "isXcodeBuildSystemEnabled" to return this build system provider variable. This will hopefully help address swiftlang#8272.
bkhouri
added a commit
to bkhouri/swift-package-manager
that referenced
this issue
Feb 19, 2025
There are a few places that check the BuildSystemProvider.Kind is Xcode to determine the build directory structure. With the upcoming Swift Build integration, which uses the "Xcode path" structure, we would need to update all instances to check the two build system provider kinds. Add an extension on the BuildSystemProvider.Kind that create a boolean variable `useXcodeBuildSystemPath`, which determines whether the build system should use the xcode path structure or not. In addition, update the code that requires a "isXcodeBuildSystemEnabled" to return this build system provider variable. This will hopefully help address swiftlang#8272 when swiftlang#8271, where it adds `case .swiftbuild: return true` to the `useXcodeBuildSystemPath`
|
@dschaefer2 : here's the PR #8298. |
bkhouri
added a commit
to bkhouri/swift-package-manager
that referenced
this issue
Feb 20, 2025
There are a few places that check the BuildSystemProvider.Kind is Xcode to determine the build directory structure. With the upcoming Swift Build integration, which uses the "Xcode path" structure, we would need to update all instances to check the two build system provider kinds. Add an extension on the BuildSystemProvider.Kind that create a boolean variable `useXcodeBuildEngine`, which determines whether the build system should use the xcode path structure or not. In addition, update the code that requires a "isXcodeBuildSystemEnabled" to return this build system provider variable. This will hopefully help address swiftlang#8272 when swiftlang#8271, where it adds `case .swiftbuild: return true` to the `useXcodeBuildEngine`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is it reproducible with SwiftPM command-line tools:
swift build,swift test,swift packageetc?swift build,swift test,swift packageetc.Description
swift-test is using the old native build path layout to find the xctest bundle when used with
--build-system swiftbuildExpected behavior
swift-test should run the tests.
Actual behavior
I'm getting an error:
swiftpm_testing_helper/Entrypoint.swift:29: Fatal error: Failed to open test bundle at path /Users/dschaefer/swift/douglib/.build/arm64-apple-macosx/debug/douglibPackageTests.xctest/Contents/MacOS/douglibPackageTests: dlopen(/Users/dschaefer/swift/douglib/.build/arm64-apple-macosx/debug/douglibPackageTests.xctest/Contents/MacOS/douglibPackageTests, 0x0101)it's actually at the following with swiftbuild.
.build/arm64-apple-macosx/Products/Debug/douglibPackageTests.xctest/Contents/MacOS/douglibPackageTestsSteps to reproduce
Run
swift test --build-system swiftbuild, orswift-testuntil the initial PR lands.Swift Package Manager version/commit hash
No response
Swift & OS version (output of
swift --version ; uname -a)No response
The text was updated successfully, but these errors were encountered: