Pre-Pitch: Add frameworkSearchPath to targets

This proposal is an extension of the linkedFramework Swift PM additions for linkerSettings found in SE-0238 (https://github.com/apple/swift-evolution/blob/master/proposals/0238-package-manager-build-settings.md). This would allow prebuilt libraries located in the package hierarchy. Using unsafeFlags lets you pass the argument -F to the command so that the frameworks can be located. However, unsafeFlags means that the library can not be linked as a dependency in another library. I would like to propose that we add frameworkSearchPaths in a similar manner to the way headerSearchPaths can be used in C targets. I don't believe allowing the passing of the frameworkSearchPath aka -F should be unsafe. This would allow adding precompiled binaries that are located in the package directory, while this is not a replacement for full binary support in SwiftPM as being discussed SPM Support for Binaries Distribution I believe it would be a decent stop gap until that is added and may still be useful after that is available.

This would be added to the following Settings:

  • LinkerSettings
  • SwiftSettings
  • CXXSettings
  • CSettings

Here is an example of the additions to the target.

targets: [
    .target(
        name: "Core",
        dependencies: [],
        swiftSettings: [
          .frameworkSearchPath(["PathToFrameworks/Frameworks"]),
        ],
        linkerSettings: [
          .frameworkSearchPath(["PathToFrameworks/Frameworks"]),
            .linkedFramework("Framework1"),
            .linkedFramework("Framework2")
         ]
     )
 ]

I have made the additions to the Swift PM source and can create a pull request if it is agreed upon.

4 Likes

It looks like https://github.com/apple/swift-package-manager/pull/2254 could be the beginnings of this sort of feature. This should at least allow you to manually add whatever unsafeFlag you want provided you’re okay with the consuming project using your library as a branch, commit, or local-based dependency.

@Aciid, is that the intention behind that PR?

Not really, but it was always a goal to allow unsafe flags in local/branch-based dependencies for development and experimentation purposes. See: SE-0238: Package Manager Target Specific Build Settings and Confused by unsafe flags being disallowed in dependencies

Terms of Service

Privacy Policy

Cookie Policy