[swift-corelibs-dev] [Proposal] [Foundation] Allowing for system bundles on Linux

[Lily Vulcano]

All,

I’m looking for feedback on a proposal I'm working on for Foundation on Linux. On Darwin OSes, we are able to provide resources from system-installed bundles in /System and /Library and locate them through the various bundle APIs (CFBundle or Foundation’s Bundle class); on Linuxes, BSDs and other Unix-y systems those paths do not exist and system resources are organized differently. We would like to start shipping resource files for Core Foundation for tasks such as providing localized content, but also store them in a way that's idiomatic when taking the system install conventions on these platforms into account, and also enable other frameworks to do so if they need to.

To this end, I’ve just sent out a PR for a proposal for installed bundles that would allow CFBundle and higher-level APIs to find code and resources installed in /usr/local or in the prefix of your choice (e.g. /opt/myapp/). In short:


 - Directories of the form <anywhere>/share/<name>.resources are recognized as installed bundles.

 - Their main executable is <anywhere>/lib/lib<name>.so (for frameworks), or <anywhere>/bin/<name> (for executable bundles). Fallbacks from/to lib32/lib64 or sbin are also allowed, and <name> will be sourced from Info.plist’s CFBundleExecutable key if present, as usual.

 - The resources path is <anywhere>/share/<name>.resources (the same as the bundle location).

 - Auxiliary executables and embedded frameworks are in <anywhere>/libexec/<name>.executables.

 - Framework headers are in <anywhere>/include/<name>/*.h, to support #include <name/name.h> syntax.

 - The layout of these directories is the same as that of an iOS bundle for their respective slice of content (e.g.: <anywhere>/share/<name>.resources/en.lproj/Localizable.strings; <anywhere>/libexec/<name>.executables/Frameworks/MyFramework.…)


Despite being at separate paths, as required by the relevant specs, these disparate locations become a single logical CFBundle; you can find the correct path using the existing CFBundle… accessor API (or the existing Bundle properties). Any path that is optional in Darwin is also optional under this scheme.

In addition to this, we will still support a ‘freestanding’ bundle structure that can be used for private or embedded frameworks, where almost all files are grouped into one directory, and Bundle APIs will continue supporting any bundle structure they already do.

The full text of the proposal is here: <https://github.com/apple/swift-corelibs-foundation/pull/1392>, and an implementation will follow shortly. Let me know if you have any feedback! ✾


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20180112/b204b895/attachment.html>