-
-
Notifications
You must be signed in to change notification settings - Fork 871
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SPM Support #1616
SPM Support #1616
Conversation
Adds conditional compilation where needed
The test error is an odd one:
The file is where it's expected to be, and it builds fine outside of the test context. If anybody has a clue, let me know 😃 |
This issue has been automatically marked as stale because it has not had recent activity. If you believe it should stay open, please let us know! As always, we encourage contributions, check out the Contributing Guide |
@mman Let's take it here.
Here's the output from my last run. It's entirely internal headers I think.
I assume the headerSeatchPath is relative to the path I've specified for the target. But I've also tried adding extras with extra leading '../'s just to make sure it's not relative to the source file. No dice 🤷🏽♂️ |
Okay. All the missing files are one or more folders deep in the internal headers folder. I think I see the problem 🙂 |
@mman There just isn't a practicable way around flattening the source tree is there? I dislike that it removes meaningful structure from the codebase. But every way around it that I find seems to suck more in the long run. If the structure remains, we end up having to encode it (so, all the subdirectories) somewhere; either in a .h file or in Package.swift. I've tried generating this list of CSettings (headerSearchPath) dynamically in Package.swift like this:
And this actually seems to work from the command line. But not at all in Xcode 😭 |
@drdaz I have flattened the tree in order to keep the So I do not say what is correct approach for this PR, I am still experimenting what works the best. for example, there are certain files for all targets, certain for iOS only, some for macOS only, some for watchOS only. Splitting these into sub targets is rather complex using current state of SPM, emitting a warning when compiling a macOS only file for iOS is also problematic as it CI, so it looks to me like a bunch of good old But flat source tree looks like a no brainer. The structure is already in the file name…. |
Closing in favor of #1683 |
These changes add support for Swift Package Manager. Files have been rearranged in a way that SPM will accept, and some significant transformations have been applied to our import statements.
This version links against an SPM-supporting fork of Bolts I've made. I'm not sure how hard it is to get FB to update Bolts, but we can move the parse-community version of Bolts to include those changes if it's an issue.
One of the biggest changes has been to move all our imports from within our own code to use relative paths. This is some of my first experience with SPM, and I feel like this shouldn't have been necessary; but I haven't found evidence suggesting there's a tidier way. If anybody more experienced with SPM knows of a better way, let me know. In case anybody's interested, to achieve that change, I donned my dusty Perl Monk / Regex Sith robe and wrote a script. There was no way I was doing that manually across hundreds of files, and I've got a soft spot for regexes and scripting (no kinkshaming plz 🤣).
Current state of SPM support:
Bolts ✅
Parse ✅
ParseFacebookUtils
ParseTwitterUtils
ParseUI
Opening this PR now to hopefully get feedback on the approach I've taken with the main Parse component.