New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'Fix' macOS build errors, TestXDG folder cleanup #988
Conversation
This fixed my recent macOS build failures. Thanks. |
@e78l XDG Test executable changes look good to me. I second your opinion of renaming xdgTestHelper to a more generic name if it helps other tests needing another process. |
I would really like to split up these fixes into a few different PRs; especially stuff about build settings vs warning fixes in CF. |
CODE_SIGN_IDENTITY = ""; | ||
COMBINE_HIDPI_IMAGES = YES; | ||
INFOPLIST_FILE = TestFoundation/xdgTestHelper/Info.plist; | ||
LD_RUNPATH_SEARCH_PATHS = "$(inherited) @executable_path/../../.. @loader_path/../../.. @executable_path/../Frameworks"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This path is wacky. Is that really the right value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm adding SwiftFoundation at the level of the build directory, so for the executable at:
Build/Products/Debug/xdgTestHelper.app/Contents/MacOS/xdgTestHelper
look for framework at:
Build/Products/Debug/SwiftFoundation.framework
Could also just copy the framework into @executable_path/../Frameworks
but that seems unnecessary to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This xdgTestHelper was only being built on Linux before, but this ports it as a .app to macOS right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
@@ -2652,6 +2722,8 @@ | |||
"-DCF_CHARACTERSET_UNICODE_DATA_B=\\\\\"CoreFoundation/CharacterSets/CFUnicodeData-B.mapping\\\\\"", | |||
"-DCF_CHARACTERSET_UNICHAR_DB=\\\\\"CoreFoundation/CharacterSets/CFUniCharPropertyDatabase.data\\\\\"", | |||
"-DCF_CHARACTERSET_BITMAP=\\\\\"CoreFoundation/CharacterSets/CFCharacterSetBitmaps.bitmap\\\\\"", | |||
"-Wno-nullability-completeness-on-arrays", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did we need to turn these off, instead of maybe fixing the warnings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Auditing CF for these warnings may be worthwhile, but I'm thinking it'll take quite a bit of time to fix+review. Meanwhile, there is a lot of noise; in particular, no-format-security
flags CFSTRs which look fine.
@@ -241,9 +241,14 @@ class TestNSHTTPCookieStorage: XCTestCase { | |||
let bundlePath = bundle.bundlePath | |||
let pathIndex = bundlePath.range(of: "/", options: .backwards)?.lowerBound | |||
let task = Process() | |||
task.launchPath = bundlePath.substring(to: pathIndex!) + "/xdgTestHelper/xdgTestHelper" | |||
#if os(macOS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should really just be using the Bundle API directly to find the correct path in the bundle, which would be platform independent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed for now (tests on mac will crash)
xdgTestHelper
is not in TestFoundation, so I would create Bundle with URL at path bundlePath.substring(to: pathIndex!)
and then get executable path?
0f39ab1
to
509c054
Compare
Hello @parkera, |
Add -swift-version 3 flag for compatibility
@swift-ci test |
For some reason status isn't being updated here after request (cc @shahmishal @erg) but the PR is testing here: https://ci.swift.org/job/swift-corelibs-foundation-PR-Linux/872/ |
Looks like it passed. Thanks! |
-swift-version 3
. Xcode seems to have a SWIFT_VERSION setting, but it doesn't have the same effect! Changes should be like those in Force use of Swift 3 compatibility mode to compile sources. #956.-Wno-nullability-completeness-on-arrays
and-Wno-format-security
for CoreFoundation - please review ifGCC_WARN_TYPECHECK_CALLS_TO_PRINTF
Xcode setting has the same effect/is better than-Wno-format-security
@slavapestov or @eeckstein - is there a way for a script to determine a mangled class/function name at build time?
The warning/error reported on macOS:
Target depends on SwiftFoundation being at same level in build directory (added rpath in lieu of framework copy phase). Perhaps copy can be disabled for TestFoundation too?
@mamabusi Are these changes okay with you?
I am thinking, perhaps, xdgTestHelper can be renamed
testHelper
or similar and used for any other 'checks' needing another process in the future.