Add support for Swift Package Manager v. 5.3 #333
Conversation
try as c setting in addition to public header path. switch to path-relative header search paths. not seeing headers I expect to see still. re-add public header path use relative path for public headers directive
…ers into include directory.
try removing include directory workaround and switching back to public header directive but pointing at root of target.
try being exacting about where to locate the protocol headers from the umbrella header. switch back to original core header file.
…clude folder via symlinks
…m existing bundle locator code.
|
Hi @mr-fixit , |
|
I'll take a look this week! Perhaps @mattpolzin could resolve the merge conflicts? |
…rly for building the Obj C test files anyway.
|
Should be good to go. |
|
Worth noting for those less familiar with Swift Package Manger: Although you can in general build Swift packages from the command line with |
| @@ -0,0 +1 @@ | |||
| ../NYTPhotoViewer.bundle/NYTPhotoViewerCloseButtonX.png | |||
There was a problem hiding this comment.
I see these PNGs are duplicated, in the new .bundle and in the new location (the Resources folder). is that necessary?
There was a problem hiding this comment.
Unfortunately, yes. One would think the resources could just be copied from the .bundle (since it is just a folder) but without the Resources folder SwiftPM will not bother to create a bundle (or at least it skips creating the SWIFTPM_MODULE_BUNDLE macro that is used here to access the SwiftPM bundle).
I did give this a shot because it made plenty of sense to me: I removed the Resources folder and its symlinked files and changed the respective copy lines of the package manifest but then I got a build error in Xcode that SWIFTPM_MODULE_BUNDLE was not defined. Reverting my change allowed me to build successfully again.
There are a few places where the symlinks in this PR could be removed up by making changes to the project structure as a whole to align more closely with what SwiftPM expects out-of-box (the Resources folder being one of those) but my approach here was to leave as much alone as possible; adding symlinks meant I did not need to change the project at large.
There was a problem hiding this comment.
Actually, I want to call out explicitly something I've said but not made really front and center so far; although GitHub makes it look like I copied a bunch of files, they are all actually symlinks. I'm still not over-the-moon about them, but at least this has not created a situation where these files need to be modified/deleted/etc. in multiple places.
There was a problem hiding this comment.
I've been looking into this, hoping to find a way to avoid adding the complication of maintaining symlinks to the resources in the .bundle. Your commit history tells me you traveled a similar road vis-a-vis the headers. I was hoping something like this would work:
resources: [
.copy("NYTPhotoViewer.bundle/NYTPhotoViewerCloseButtonX.png")
but found this bit of code causes NYTPhotoViewer.bundle to be added to the sources, not the png.
I'm still wrapping my head around the internals of SPM, but I'm thinking the final answer will be to reorganize the resources and includes of NYTPhotoViewer so that SPM can be supported without symlinks.
There was a problem hiding this comment.
That makes sense. If it were mine to maintain, I would prefer the project reorganization over the symlinks as well.
Let me know if there’s anything else I can do to help out. I’m no expert, but I do have a bit of history with SPM at this point.
There was a problem hiding this comment.
I asked about this on the Swift forums, see https://forums.swift.org/t/package-resources-from-a-directory-named-with-an-extension/43423
|
@mattpolzin, I've opened up #338 which is your work + rearranging file hierarchy to avoid the need for symlinks. Could I ask you to take a look? |
|
Closing in favor of #338 |
Add support for Swift Package manager by adding a package manifest and creating a few symlinks where the current directory structure of the project was a bit inconvenient or even incompatible with representation in the package manifest.
This requires version 5.3 of the package manager in order to fully support this project including the bundled images.
Closes #332.