Closed swift-ci closed 5 years ago
aciidgh
commented
6 years ago Thanks for the writeup wjk (JIRA User)! A couple of SwiftPM contributors are working on a draft proposal for resources. They expect to put it out for discussion this fall (it'll take some time due to upcoming vacations).
swift-ci
commented
5 years ago Comment by Richard Venable (JIRA)
@aciidb0mb3r You mentioned there would be a draft proposal for resources expected last fall. Did that get published?
swift-ci
commented
5 years ago Comment by Bastian Mueller (JIRA)
@aciidb0mb3r Any update on this?
Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Package Manager | |Labels | New Feature | |Assignee | None | |Priority | Medium | md5: d271df3cd846c6aaee6d69dcff44cb9eduplicates:
Issue Description:
Greetings Swift community.
I noticed while browsing the issues that swiftpm has no support for handling bundle resources. I had a few thoughts on how to implement that, which I would like to share before starting implementation in case anyone has any feedback:
Resource files for a hypothetical module Foo would be stored in `Resources/Foo`, alongside `Sources/Foo` and `Package.swift`. The Xcode project generator would create appropriate Xcode rules to have these files copied into the Resources directory of the target. All files in the `Resources/Foo` directory would be copied, except if the name starts with a dot (so that .gitignore, .DS_Store, and so on are automatically ignored). Subdirectory structure would be reproduced as-is, including *.lproj directories. (If generating for Xcode, then we would need to special-case these to use the proper Xcode conventions.) If there is a file called `Info.plist` in the root of the resources directory for the module, it would be set as the Info.plist file for the target in lieu of the one automatically generated by swiftpm (and not copied into the Resources directory, as that is considered incorrect behavior by Xcode).
If the developer is targeting a non-Apple platform, then a `Foo.resources` directory will be created next to the native binary and the resources copied there, such that the resulting structure would be compatible with the CFBundle implementation in swift-corelibs-foundation. The Info.plist would be copied in this case, as is required.
If on any platform the `Resources/Foo` directory should be missing, then it will be silently ignored. If targeting an Apple platform, then a default Info.plist should be generated, as swiftpm does already. If targeting a non-Apple platform, no message should be printed about a missing Info.plist, nor should one be generated by default. (This is because the library in question may not be using CFBundle, and as such creating .resources directories where they are unneeded would be a pointless activity.)
There are a few things I am unsure about, however:
If targeting an Apple platform but not using Xcode (i.e. `swift build` from the command line directly), what should we do?
If building for a non-Apple platform, how should we ensure that the .resources subdirectory is copied alongside the binary? If we separate the two, then the library may fail when it can't find its resources.
I am unsure how to generate the pbxproj constructs required to properly copy the resources. The best resource I have for pbxproj processing is the xcbuild project (https://github.com/facebook/xcbuild,)), but that is licensed under Facebook's unfriendly BSD+patent license, so I am hesitant to use it as an implementation resource. I may require the assistance of someone who knows more about Xcode here.
Thanks!