You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SR-2866 [SwiftPM] Need a way to include resources with targets
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!
The text was updated successfully, but these errors were encountered:
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).
Additional Detail from JIRA
md5: d271df3cd846c6aaee6d69dcff44cb9e
duplicates:
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!
The text was updated successfully, but these errors were encountered: