IGListKit
IGListKit copied to clipboard
Swift Package Manager support
Changes in this pull request
Added proper support for Swift Package Manager (SPM).
-
"inverted" the current master's files structure by putting all public headers to the
includefolder and all internal/private moved to the package's root. Swift Package Manager documentation -
created symbolical links for IGListKit with the relative path to IGListDiffKit's private headers to work around an issue for private headers search path. Seems like it works pretty well for SPM, cocoapods and original Xcode workspace.
-
added macOS Catalyst support
Supported targets:
- IGListSwiftKit
- IGListKit
- IGListDiffKit
TODO:
- [x] add a way to test SPM support.
Issue fixed: #1368 #1406
Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the
CHANGELOG.mdfor any breaking changes, enhancements, or bug fixes. - [x] I have reviewed the contributing guide
Not sure how to trigger CI?
So strange. If you checkout on commit c2caf741657552458560b25a4fe14655eb40a1ef IGListKit can be built as a Package from Xcode without errors, but if you try to integrate it as a dependency on a regular Xcode project as soon as you try import IGListKit you will see a compilation error. Maybe it's an Xcode bug since it's definitely related to the headers search path since imports in angle brackets (<IGListDiffkit/someheader.h> ) can't be resolved by the Xcode project which depends on IGListKit
I made some more experiments and moved all public headers to the include folder and changes all import to use local mode with double quotes "IGListDiffkit.h". This seems to work for IGListKit as a Swift package (from Xcode) and can be imported as a dependency for some regular Xcode project ( I have to define USE_PACKAGE_FROM_XCODE to properly manage imports). So the latest commit seems to work, now need to figure out if other things don't break cocoapods (lint passed locally, but I have doubts whether it works on real projects), unit test.
Hey hey, thanks for working on this! I also tried out a bit but couldn't figure out how to go around the file structure thing.
Looks like your latest approach is to change the files structure to go around the search path thing from Xcode setting, do they work in your latest version? I think it would be a bummer to change all the <IGListKit/XXX.h> to be "XXX.h" format within the library here. But let's see how it goes.
Hey @lorixx! Yes, I've "inverted" the current master's files structure by putting all public headers to the include folder and all internal/private moved to the package's root. Swift Package Manager documentation
- created symbolical links for IGListKit with the relative path to IGListDiffKit's private headers to work around an issue for private headers search path. Seems like it works pretty well for SPM, cocoapods and original Xcode workspace.
So far I was able to verify:
- that the cocoapods support works as expected, and projects from the Example folder passed tests (iOS one).
- Xcode 12 SPM integration work as expected.
I have some issues with running unit tests from Xcode locally, but it's the same issue in the current master (my env is Xcode 12.0.1, Xcode 11.7). I see that .travis mapped to Xcode 10.2 but maybe there is some other way to make it work on a newer environment? BTW. do you trigger CI manually?
BTW. do you trigger CI manually?
@3a4oT I think one issue I saw might be related here is that the PR is in "Draft" mode, thus it doesn't trigger the CI I believe, for example https://github.com/Instagram/IGListKit/pull/1430 this PR triggered the CI.
We moved most of our dependencies to SPM because Cocoapods doesn't play very well with Xcode 12. The only thing thats missing is IGListKit. Any Progress on this one?
I have some other work right now, but my plan is to alloc some time during the upcoming weekend. :)
So I take another attempt to synchronize the test environment before continuing work with this PR. As part of this attempt, I've created PR which allows us to run tests from Xcode 12, and added Github workflow to verify it. @lorixx, would be awesome to get feedback on https://github.com/Instagram/IGListKit/pull/1478 before I continue with this one. Thanks in advance.
And converting this PR form a "draft" doesn't trigger the original Travis CI tests. I think POC is ready and would be nice to somehow run the tests.
Tests (github workflow) passed on my fork: https://github.com/3a4oT/IGListKit/actions/runs/368991395
@lorixx friendly ping ...
Thanks again for working on this! Does this work for the other integrations? Cocoapods and Carthage. Also looks like this change added a new github CI support which is great, did you get the build/test result from the previous travis CI tool? cc @bdotdub @maxolls @Ziewvater We might need to discuss the overall code structure change here.
Hey @lorixx . Yeah, Carthage and cocoa pods passed. The latest test results can be found here https://github.com/3a4oT/IGListKit/actions/runs/372069244 . I have opened separate PR for CI support if you want to go it first for better visibility.
Hey @lorixx . Yeah, Carthage and cocoa pods passed. The latest test results can be found here https://github.com/3a4oT/IGListKit/actions/runs/372069244 . I have opened separate PR for CI support if you want to go it first for better visibility.
yeah I think it's better to decouple the SPM support and the new Github CI support, since they are doing different things and related to each other.
https://github.com/Instagram/IGListKit/pull/1478 CI
@3a4oT Just tested out your spmBrain branch in my project and everything is looking great! I'll have our QA poke around and see if they find any issues but so far so good. Nice work :)
Just an update, no issues found! Seems production ready to me!
@lorixx is there a timeline available for getting this merged? We've actually pushed this to our production environment without issue, glad to finally be free of cocoapods!
@RamblinWreck77 thanks for the feedback!
Any progress on official support?
any update on this?
You know what I'm going to ask :)
Hey folks! Sorry to revive this old thread. I'm going through the list of PRs now and seeing which ones we can close out in preparation of a new version launch.
It seems to me that this PR was further refined down the line and this was used to create the SPM setup we have today. I can definitely confirm that SPM support works great now (We're using it for the sample projects now!) so I think we can close this PR out having done its job.
Thanks again for all your contributions!