[FHS bundles] Proposal #1392
[FHS bundles] Proposal #1392
Conversation
|
As a formality: @swift-ci Please test. |
Docs/FHS Bundles.md
Outdated
|
|
||
| Function | Path returned | ||
| ---|--- | ||
| `CFBundleCopyBundleURL` | `…/MyFramework.resources` |
There was a problem hiding this comment.
Just to be sure: does ... mean the parent directory?
There was a problem hiding this comment.
It meant 'the same directory as … in the other entries', but I see how it can be confusing. I will clarify this.
Docs/FHS Bundles.md
Outdated
|
|
||
| ### Bundle Paths | ||
|
|
||
| The bundle's `.resources` directory contains resources much like an iOS-style flat bundle. Unlike on iOS, however, executables are not contained directly inside this directory. Instead, given that the bundle exists in `share/MyFramework.resources`, then an installed bundle will source from the following additional paths within the prefix the bundle is installed in (the parent directory of the `share` directory): |
There was a problem hiding this comment.
Can you include reference to some document which explains iOS-style flat bundle? I see many references to the iOS bundle in this proposal.
There was a problem hiding this comment.
|
Hi @millenomi - from my reading of FHS As Foundation runs on platforms including Linux on z Systems (LinuxONE) and Linux on POWER it's important that we have a cross-architecture approach. Just checking that this has been considered in your thinking. Perhaps you could elaborate how this would work. Thanks! |
|
The idea is that bundle resources, which are for all bundles we intend to ship this way architecture-independent, will live under |
|
Thanks @millenomi that sounds good. One other thing. I imagine that in future we intend to ship bundles containing Foundation resources as part of the Linux toolchains from swift.org (for things like localization content), so we'd have a How would this work when a user wants to have multiple versions of Swift installed on their Linux machine, which would ship with different bundle content? |
|
I'm going to circle back to you about that shortly, but the preliminary thought is that right now no two released versions of Swift are able to coinhabit the same |
|
Perfunctorily, @swift-ci Please test. |
| An installed bundle exists if there is: | ||
|
|
||
| - A directory with the `.resources` extension; | ||
| - contained in a directory named `share`. |
There was a problem hiding this comment.
Is this complete? I found myself wondering "anywhere?". I presume this is limited to /usr, /usr/local, etc? Also, do any relative paths to a process working directory come into play?
There was a problem hiding this comment.
Would it be conceptually constant for /usr/lib/libfoo.so to also be a "bundle"? The reason I ask is that it seems a little anomalous that it would be a library for a bundle only if there is also a .resources present. I could imagine that lifting this restriction might allow client code to be more consistent.
This isn't a well formed idea, please disregard if it doesn't make sense to consider.
There was a problem hiding this comment.
This is complete. As long as the CFBundle code finds that its client is trying to create a bundle at $PREFIX/share/$NAME.resources, we treat it as a FHS installed bundle. This is to support installing bundles in any --prefix=$PREFIX.
There was a problem hiding this comment.
I also briefly considered using the library as the lynchpin of an installed bundle, to allow for resource-less bundles. This hits an issue I'd like to avoid: it means that at least for some bundles, their location would not be a directory URL, which is not quite part of the contract but it is something I gather people would be severely surprised by.
Since the point here is to allow finally shipping resources, I would feel personally OK with restricting this proposal to only work with bundles that do have a resources path.
| - Executable bundles will search `bin`, then `sbin`, for an executable with the same base name as the resources folder, plus any platform prefix or suffix for executables. e.g.: `bin/MyApp`. | ||
| - Framework bundles will search the appropriate `lib…` directories for a library of the same name, adding appropriate platform prefixes or suffixes for shared library file (falling back to just `lib` otherwise). e.g.: `lib/libMyFramework.so`. | ||
| - Auxiliary executables and libraries will be in, or in subdirectories of, `libexec/MyFramework.executables`; | ||
| - For framework bundles, `include/MyFramework` will contain headers, though this directory does affect the return values of the runtime API. |
There was a problem hiding this comment.
Will we also support a Modules directory like we do for frameworks? One reason this distinction is important is that a framework module map is written differently (framework module) than one for flat headers, and there may be something we want to do to reconcile this (presumably Clang itself isn't going to start understanding this convention).
There was a problem hiding this comment.
Good question. I'll circle back to you on that.
There was a problem hiding this comment.
So.
This document does affect the discussion you mention, but right now we're a little more interested in the runtime aspect of this. The compile-time aspect is additive, and we can set that up with the clang team as a follow-up from implementing this — there's no runtime API that is affected by the presence (or absence) of the headers or of the module file, as far as I can tell.
There was a problem hiding this comment.
That makes sense. I don't see any issues with tackling that later.
millenomi
changed the title
|
We seem to have reached some consensus. I will write SRs for the remaining tasks, and we can continue discussion on the forums if needed once they're up. @swift-ci Please test and merge. |
|
Ahem. @swift-ci Please test and merge. |
|
Looks like there was a transient issue. I'll just force-merge this, since it has no code changes. |
Please leave comments here or at the thread I'm about to start on the swift-corelibs-dev list.