Cascading Swift Support Search #26388
Conversation
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
|
Build failed |
|
Build failed |
Support searching for `swiftrt.o` in the SDK or the compiler resource directory. This allows for a more flexible setup and was suggested by @jrose-apple in a previous commit.
Adjust the library search path so that the normal build of the runtime/sdk overlay can be used as the SDK content. This allows for the rest of the search to be cascading.
Post-commit discussion with Jordan yielded another approach which is viable and allows for cascading searches. Revert the initial change opting for the cascading search.
|
@swift-ci please test |
|
Build failed |
|
Build failed |
| @@ -1200,6 +1195,9 @@ void ToolChain::getRuntimeLibraryPaths(SmallVectorImpl<std::string> &runtimeLibP | |||
| scratchPath = SDKPath; | |||
| llvm::sys::path::append(scratchPath, "usr", "lib", "swift"); | |||
| runtimeLibPaths.push_back(scratchPath.str()); | |||
|
|
|||
| llvm::sys::path::append(scratchPath, getPlatformNameForTriple(getTriple())); | |||
| runtimeLibPaths.push_back(scratchPath.str()); | |||
There was a problem hiding this comment.
This doesn't make sense either. Right now there's no difference between an SDK and a sysroot; we should not have platform-specific subdirs in a sysroot. (Architecture, maybe, but not platform.)
There was a problem hiding this comment.
I agree with you on that in principle. The problem is that the current swift build doesn't have a way to do this. I think that doing this improperly and then working to address the limitation in the swift build is an effective way forward. I've tested this set of changes and it is sufficient to build libdispatch, foundation, xctest. Without this, the builds do fail.
The layout is something that I will be bringing up on the forums as well because I think that we need to figure this out to get some stability going forward.
There was a problem hiding this comment.
The problem is that the current swift build doesn't have a way to do this.
I'm not sure what you mean. The "current Swift build" is Apple platforms and "Linux", plus perhaps the platforms tested by the ci-external bots. What scenario are you actually trying to handle by searching for $SDK/usr/lib/swift/$PLATFORM/swiftrt.o?
There was a problem hiding this comment.
I meant that the current CMake setup in the swift repository doesn't have a way to generate the desired layout. I'd like to improve that, but, doing the split build is extremely helpful and I'd like to have that working as we start to iterate on the CMake support to build the SDK layout.
There was a problem hiding this comment.
Why do we care about the CMake support producing the desired layout, rather than needing a post-processing step?
There was a problem hiding this comment.
Well, ideally, we wouldn't need to have a post-processing step. In the ideal mythical configuration, we would use the LLVM's distribution mechanism to control which pieces are installed into a distribution image, which is fully ready to use and installed to the location of choice (that is, you just specify the DESTDIR= to say where you want the image rooted). You can just package that up or copy that to another location and just use it.
There was a problem hiding this comment.
Yes, but while we're in the non-ideal world, I'd prefer that cross-compile configurations need a bit of manual fix-up rather than the compiler adding default search paths that don't make sense.
There was a problem hiding this comment.
We are just coming at it from a different perspective I suppose. I would prefer that we do the work in the driver until the build works, and you would prefer that some other entity do the work until the build does it. Does it make that much of a difference?
There was a problem hiding this comment.
Well, yes. If it's in the compiler, people start depending on it, and it can have effects on configurations other than the one we care about, and it affects other contributors who now need to take the case into consideration.
There was a problem hiding this comment.
There already are a number of incorrect things in the layout that people may be depending on. If this is specifically about Darwin, I can easily limit this to non-Darwin targets. That said, I do agree that if we can avoid it, its better. I've start working on this in #26409 which tries to build up the SDK image. Probably would be a good idea to identify the missing pieces.
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.