That is indeed off-topic for this thread. This is trying to homogenize the handling of the Swift development content and the system platform content so that building for various different platforms is a similar experience.
I guess I felt it was relevant because it touches on that very topic of platform homogenization, and whatever solution is developed to help Linux should not prevent Apple from (hopefully someday) fixing the issue created by their distinct sdkroots for Device and Simulator.
They are different platforms. The executable build for the simulator is a MacOS program running on an Intel chip, and the executable runs natively without ARM emulation. The device is an ARM device. The compilers and linkers take care of converting to each binary format from the same source code. The simulator libraries probably differ because of the need to simulate/emulate the functions of the various specialized chips in the devices. Different architectures, different register layouts, different ABI, etc..
I get that. But it makes it very hard to develop a library to be used in an iOS application that can target device and simulator with ease. You have to compile the library source code multiple times, then combine the resulting objects into a single universal binary. Xcode doesn't make this easy, and Apple doesn't seem to care, but the practical reality is that this is necessary. I don't mean to derail this topic with the specifics, but this problem speaks to the considerations of how platforms are treated.
I suspect for Linux on X86_64 architectures, homogenization being discussed is really accounting for differing vendors ideas on how to layout developer/user environment in Linux, as it was in Unix, BSD-land, System-V land, etc.. However, for Android, Linuxes on different architectures like ARM, you are still going have differing SDK roots because of the computer architectures.
I guess having gone through the 68000, PowerPC, and Intel transitions for the Mac, this doesn't seem to be out of the ordinary. It may mean you have to write scripts at the end to lipo libraries together, but, we've had to do that for a long time.
You don't have to when building for multiple architectures on a single platform (i.e. when targeting a device, Xcode will build all the appropriate architectures for the various ARM variants. But you can't get it to add x86, because that's a separate platform, with a separate sdkroot)
I understand where you're coming from. I think XCFrameworks will probably be a big help. If you want to provide libraries, you'll have to lipo the separate X86/ARM binaries into a universal library. Yes, you still have to build each separate architecture, but, you would have to do that anyway, unless we get an ARM Mac. Or, provide a development environment on iPads.
I was about to reply, but I realize I'm really hijacking this thread and I don't want to do that any more. These considerations involve more than just Swift layout on Linux.