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.)

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.

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?

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.

Why do we care about the CMake support producing the desired layout, rather than needing a post-processing step?

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.

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.

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?

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 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.