labath added a comment. I don't think that spreading this out over host and platform is convoluted. In fact, I was going to propose something like that myself. However, it does bring us back to the question of the "linux" sdk.
A couple of comments ago you said: > The "Linux" SDK is a placeholder of sorts when debugging a Swift-on-Linux > server application (e.g., something like https://www.kitura.io/) from > *within* Xcode that points to a directory that contains the Swift > resources/stdlib cross-compiled for Linux. When you say "cross-compiled", I am imagining that the resulting binary will be a regular linux elf file, and it's triple will be detected as `***-linux`. So, `Platform::GetPlatformForArchitecture(GetArchitecture(), nullptr)` will return PlatformLinux, and the subsequent `GetSDKPath` will return blank, whereas I am expecting that you would want it to return `HostInfoMacOSX::GetXcodeSDK(linux)` (if running on macos). So, if all of this is true, and we want this interface to reside on the Platform class, then I think the implementation of `GetSDKPath` needs to be spread out over the individual platform classes, which would delegate to the appropriate host api. E.g. `PlatformLinux::GetSDKPath` (with no arguments) would be implemented via `HostInfo::GetXcodeSDK(linux)`, `PlatformRemoteAppleWatch::GetSDKPath` as `HostInfo::GetXcodeSDK(watchos)`, etc. This would give us maximum flexibility. For instance one could implement `HostInfoLinux::GetXcodeSDK` to locate the xcode sdk through some other mechanism, and then cross-debugging mac binaries would work too. Or, one could implement `PlatformXXX::GetSDKPath` to download the sdk from the remote system somehow if it is not found on the host, and then we would be able to debug on any host. However, I found all of these scenarios fairly unlikely, which is why I said that going straight for the host seems fine. The interface is still sensible -- we just say that the host system has to provide the sdks for any of the listed platforms. And if the host doesn't provide that, tough luck. That setup can always be generalized if we have a need for it. In D76471#1954045 <https://reviews.llvm.org/D76471#1954045>, @JDevlieghere wrote: > I think the current separation makes a lot of sense, but I don't like that > `XcodeSDK` class is part of Utility. I understand the need from a layering > perspective and I don't really have a better idea, but maybe someone else > does? We could move it up to Host, and have it be next to the `HostInfo::GetXcodeSDK` function which returns it. Would that look any better? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76471/new/ https://reviews.llvm.org/D76471 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
