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
Xcode Project Generation #174
Conversation
The command will be |
No, I imagine it will be swift build @ddunbar thanks will address these. |
Overall this seems like a great start and I'm sure will be immediately useful to people. We should probably also update the README.md to explain how to start developing with it? |
Indeed, will amend. Expect a few more patches before this is merged. |
buildSettings["LD_RUNPATH_SEARCH_PATHS"] = "'@loader_path/../Frameworks'" | ||
} else { | ||
//FIXME Xcode fails to set this for some reason | ||
buildSettings["LD_RUNPATH_SEARCH_PATHS"] = "/Users/mxcl/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-03-01-a.xctoolchain/usr/lib/swift/macosx" |
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.
Incidentally @ddunbar, did this not cause you problems? And if it didn't cause you problems, did the tests still pass? I added it temporarily because it seemed to be needed. Obviously needs to at least be the local toolchain.
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 caused swift-build
to fail to run with error
dyld: Library not loaded: @rpath/libswiftSwiftOnoneSupport.dylib
I got this working by making the following change
if let buildToolPath = try? POSIX.popen(["xcrun", "--find", "swift-build-tool"]),
let dylibsPath = try? Path.join(buildToolPath, "../../lib/swift/macosx").abspath() {
buildSettings["LD_RUNPATH_SEARCH_PATHS"] = dylibsPath
} else {
//FIXME: handle this properly
fatalError("Unable to get path to toolChain")
}
Fresh review please, no nit-picking, let's merge this. |
@swift-ci Please test |
Will squash history and merge later today unless there are objections. |
Looks good, lets merge asap 💃 |
This global state was making everything less testable, in the end I realized mostly it was there for ManifestParser, so now the paths to that are injected. A bonus is that Get no longer depends on ManifestParser which is a more restricted dependency diagram and makes the module more testable too. I also removed the code that figures out the Darwin path to the executable using dlsym. Perhaps this is foolish, but `Process.arguments.first!` seems as good and doesn’t have an initialization order problem, and since XCTest exposes no way to statically initialize global state, I don’t want to deal with it. This refactor exposed bad test boundaries for TransmuteTests and GetTests that must be fixed due to the hacks I had to add to the test dependency calculator in the Transmute module. —————— Though I am not so happy with the injected manifestParser() function in Get. It feels dirty to pass it around to every object, but thus is the pattern.
We create dynamic libraries for modules since there is no concept in Xcode itself of a target that has no binary product (SwiftPM compiles the modules but the eventual binary products are declared separately, so two modules can be linked into the same binary target). There are things left to do, see TODO.md.
@swift-ci Please test |
|
||
let srcroot = package.path | ||
let nontests = modules.filter{ !($0 is TestModule) } | ||
let tests = modules.filter{ $0 is TestModule } |
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.
Just being cheeky, but aren't these supposed to have spaces before the closures? 😏
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.
No.
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.
Usually yes, unless you wrap the closure around params.
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.
Swift: the two year old language where apparently we already have extremely firm guidelines for whitespace.
tap tap tap… come on CI. |
😍😍👍👍 |
Hmm, looks like PS: I have exported the toolchain to PATH |
|
At this point I'm not exactly sure yet what to do here.
You should set I think maybe the solution is to just use |
I think it needs the 7.3 beta for TOOLCHAINS to work, can't confirm right now as on slow internet can't download 4GB 😔 |
This is all a hack anyway since Xcode shouldn't need to be told which |
Actually this will work if it's in a toolchain since it looks next to itself first. So this only affects people trying to use a self built copy of |
A workaround for now is:
|
As a temporary work around, I got things running by export SWIFT_EXEC=/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin/swiftc Best part, it is even setting I'm still on Xcode - 7.2 btw |
I've tried many options and I still get en error.
I still get this error.
Here is log from the ``Utilities/bootstrap
I use latest Xcode 7.3beta. |
@kostiakoval you need to clean the build for swiftpm, this is a separate issue caused by the swift-3-api-guidelines merge. Though I do not know what happened there, it broke our incremental build. Which is worrying. |
However this whole system is not robust, we should open a ticket to fix it:
|
No description provided.