search

JamitLabs / Accio

A dependency manager driven by SwiftPM that works for iOS/tvOS/watchOS/macOS projects.
MIT License
664 stars 32 forks source link

Issues with SwiftEntryKit #58

Closed fredpi closed 5 years ago

fredpi commented 5 years ago

Issue

In one of our projects, we use the SwiftEntryKit dependency. With the current version of Accio (0.6.1), building it doesn't work, but strangely it works with version 0.6.0.

Reason

The commit that broke things for this dependency is https://github.com/JamitLabs/Accio/commit/779e3fc449863c88e32a90cfcf340d535829bedb. This commit is actually a fix not to destroy the Xcode project generated using Swift PM right after creating it – so it's definitely valid. Still, with this commit, Accio now creates an XcodeProject using SwiftPM for the SwiftEntryKit dependency. When opening this project manually, one can easily see why it doesn't build: Many import statements are missing (~ import UIKit), in files such as Source/Model/EntryAttributes/EKAttributes+FrameStyle.swift.

So far, so good. But why does it build when the XcodeProject isn't generated?!

The reason is that Carthage isn't as smart as Accio in excluding folders like Example and Demo from a scheme / xcodeproj search. This is why it finds a Xcode Workspace within the Example folder and is actually able to build this workspace correctly; it however includes the example project as a side result... Opening up this workspace manually, there are no such issues with import statements as with the SPM-generated xcodeproj, although the files are the very same. I don't understand this by now...

Further Steps

This mostly sounds like an issue with the project itself that can be solved by fixing theimport statements. However, it poses the question whether such project configurations are more common than expected and whether Accio should do something to detect them and act accordingly.

Also, how the hack are those missing import statements within the Xcode workspace even valid?!

Jeehut commented 5 years ago

This sounds to me like SwiftEntryKit doesn't support Carthage properly. When a Demo project is included, then how is this supposed to be correct? Thus, the correct fix would be to implement the Carthage support on SwiftEntryKit properly by providing an Xcode file with shared schemes somewhere outside of a "Demo" or "Example" folder IMO.

fredpi commented 5 years ago

You're re right, this is probably a singular issue instead of a common configuration. I will request a fix on SwiftEntryKit's side and close this.