Conversation
Currently, XcodeProj is not compilable on iOS platform. This is an issue when attempting to compile products that have XcodeProj as a (transitive) dependency
|
@fortmarek @cschmatzler @asmitbm could you please take a look at this and let me know your thoughts? Thanks a lot |
|
@nmcc24 this package was not designed for running on non-macOS platforms, so even if you make it compile, some features might not work. I'd suggest to use conditional linking when declaring a dependency on this package to specify that it should only link it when building against the macOS platform. |
|
Hi @pepicrft thanks for your comment. I completely understand and appreciate it, and in all honesty I don't think it would make any sense to run the targets on iOS. However, it is impossible to restrict a swift package from being compiled on iOS ( if we don't declare the platform, it will fallback to a minimum version). Having said that, and in the context of my problem where this transitive dependency is not allowing the compilation of a build plugin that will run at compile time of a product targeting the iOS platform, this suggested approach would solve this problem without bringing any side effect that doesn't already exist on any swift package. I'm of course open to any other approaches that come to mind :) |
|
@nmcc24 thanks a lot for the context, I appreciate it. Wouldn't Target(name: "MyTarget", dependencies: [
.product(name: "XcodeProj, condition: .when([.macOS]))
])
|
|
Hi @pepicrft Firstly, apologies for my late response - somehow I missed your response. Im afraid declaring the dependency conditionally is not the tool for the job, not without heavily modify any consumer of XcodeProj. And I genuinely don't think that is the way forward when facing this issue involving Swift Packages. Based on my observations highlighted previously, a Swift Package is platform agnostic - meaning its source code must compile regardless of the platform. A recent example I have found of this is the comment highlighting this very same situation on other projects. With that said, guaranteeing the code compiles for legit reasons seems to be the way Apple/Swift intended with packages. However, that doesn't mean the code/functionality must or should work. In the case of XcodeProj (and the one i'm applying it to), its functionality won't ever be utilised outside of MacOS (Xcode projects don't exist in any other Apple platform). |
|
👋🏼 @nmcc24
I disagree. I think the runtime and compile-time compatibility must align. Otherwise, we are trading convenience for confusion (i.e., developers might expect this just works on iOS). The build system has the right primitives to enable conditional linking and symbol inclusion, so it should be used. I'm fine with adding support for iOS. Who knows... some people might try to do some Xcode project manipulation from that platform, but in that case we should make sure the logic works in that platform validating that through unit and integration tests that run on that platform. |
|
@pepicrft thanks for coming back to me. And it is completely fine that we disagree - i'm happy to follow your lead as you know better your project's vision :) Are there any particular areas you'd like me to focus on? For instance, XCTestCase+Shell.swift won't be possible to compile on iOS due to the usage of Process unavailable on Mac. I assume there are other cases like that and you may know them already? |
3d430a8 to
3ce1a9c
Compare
Resolves #1015
Short description 📝
Solution 📦
Implementation 👩💻👨💻