<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">All,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> - Directories of the form <b class=""><anywhere>/share/<name>.resources</b> are recognized as installed bundles.</div><div class=""><br class=""></div><div class=""> - Their main executable is <b class=""><anywhere>/lib/lib<name>.so </b>(for frameworks), or <b class=""><anywhere>/bin/<name> </b>(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.</div><div class=""><br class=""></div><div class=""> - The resources path is <b class=""><anywhere>/share/<name>.resources</b> (the same as the bundle location).</div><div class=""><br class=""></div><div class=""> - Auxiliary executables and embedded frameworks are in <b class=""><anywhere>/libexec/<name>.executables</b>.</div><div class=""><b class=""><br class=""></b></div><div class=""> - Framework headers are in <b class=""><anywhere>/include/<name>/*.h</b>, to support #include <name/name.h> syntax.</div><div class=""><br class=""></div><div class=""> - 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.…)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">The full text of the proposal is here: <<a href="https://github.com/apple/swift-corelibs-foundation/pull/1392" class="">https://github.com/apple/swift-corelibs-foundation/pull/1392</a>>, and an implementation will follow shortly. Let me know if you have any feedback! ✾</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>