[Toolchains] - Generalize lookup routines as a Toolchain extension. #26
Conversation
Once swift-driver is installed in the Toolchain, we can look for tools right next to it's executable path, this help us to be more platform agnostic while locating the toolchain. This is the first step in this direction, we will need to make this more robust to get rid of xcrun if possible, and get a proper linux implementation.
| func lookup(exec: String) throws -> AbsolutePath { | ||
| if let overrideString = envVar(forExecutable: exec) { | ||
| return try AbsolutePath(validating: overrideString) | ||
| } else if let path = lookupExecutablePath(filename: exec, searchPaths: [executableDir]) { |
There was a problem hiding this comment.
Could this be lookupExecutablePath(filename: exec, searchPaths: [executableDir] + searchPaths)?
There was a problem hiding this comment.
Looking for searchPaths in macOS was crashing. Later today I will dig into it to find the real reason and will provide a detailed response or the fix.
There was a problem hiding this comment.
The issue here is that after we find the swift compiler path in the searchPaths, we cannot find the resource directory under ~/usr/lib/swift/.
is macOS supposed to have a resource directory at ~/usr/lib/swift/, or what is the correct way to handle this?
There was a problem hiding this comment.
Ah, the resource directory is in the Xcode toolchain on macOS, inside /Applications/Xcode.app/Contents/Developer/Toolchains/<dir>.xctoolchain
There was a problem hiding this comment.
Now we first look in the executable path, then go to xcrun, and finally look into the searchPaths.
This is the "best" approach right now because in macOS the toolchain lives under Xcode, not under the Swift executable in ~/usr/lib/swift/.
|
We definitely want to un- |
|
@DougGregor some of your comments in #25 are addressed here. |
JhonnyBillM
force-pushed
the
SWIFT-DRIVER-OVERRIDES-YOU-AND-ME
branch
from
17ff55d to
6640ed5
Compare
Why were those tests failing? They were failing in my Docker instance¹ because it doesn't have I was looking to see if those tools are in GNU, and I thiiiink they are, but I am not sure about Tests are working because of this hack, and although this is outside the scope of this PR, in order to get rid of the previously mentioned hack in a future PR, I would like to know: • Does swift-driver requires ¹ Configured following this steps |
|
|
|
Ok so, can we move forward with this PR and discuss those things in a future PR when trying to remove the aforementioned hack ? |
|
@swift-ci please test |
|
Hmm. Makes me wonder if we picked an old clang instead of the one next to swift? Can you add some tests that we find a clang path that’s relative to the swift path for a given toolchain? |
UPDATE - XCTestManifests.swift
|
Done. This was interesting, moved the hack to This work will benefit from #25, should I keep that as a separate PR, or should we merge those changes into this PR and move forward with "1 big change"? |
|
@swift-ci please test |
|
This is looking good; I'll go ahead and merge this and we can iterate on #25 separately. |
|
Thank you @harlanhaskins for all your help in this PR. And thanks @DougGregor for reviewing + merging. |
This generalizes
lookup(exec:)and exposesenvVar(forExecutable:).Due to the generalization, the following tests were failing in Linux:
testDSYMGeneration: unableToFind(tool: "dsymutil")testLinking: unableToFind(tool: "libtool")testStandardCompileJobs: unableToFind(tool: "dsymutil")testLinkingalso failed in macOS when specifying the linux target.So, I ifdef them out, but if we need to do anything else in the test suit, just please let me know.