<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I'm trying to package a Swift library. This Swift library is tightly coupled to a native library. By "tightly coupled" here I really mean that only half the library is written in Swift, and the other half, as an implementation detail, is in some other language.<div class=""><br class=""></div><div class="">You *probably* do not have a build environment for this other language just lying around, so my plan (actually, my current practice) is to distribute binaries of the non-Swift part, just checked into source control, and then link against them with a module map. Yes, I realize this isn't portable, but neither is anything else in this project, so I'll save that particular surprise for another day.</div><div class=""><br class=""></div><div class="">The trouble is, <a href="https://github.com/apple/swift-package-manager/blob/master/Documentation/SystemModules.md" class="">swiftpm wants there to be some "other" repo called `CFoo` containing only a modulemap with paths that point to... /usr/local I guess?</a> But </div><div class=""><br class=""></div><div class="">1. There is no other repo</div><div class="">2. You have not installed the non-Swift half of my library to /usr/local</div><div class="">3. You do not want to link against "some" version of the binary blob you have lying around from times past. You want to link against exactly the one I give you, because the work is versioned as a whole.</div><div class=""><br class=""></div><div class="">I see two solutions to this problem.</div><div class=""><br class=""></div><div class=""># Non-URL dependencies</div><div class=""><div class=""><br class=""></div><div class="">Behind this door, I can write a Package.swift like this:</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class="">let package = Package(</div></div></div><div class=""><div class=""><div class=""> name: "Foo",</div></div></div><div class=""><div class=""><div class=""> dependencies: [</div></div></div><div class=""><div class=""><div class=""> .Package(path: "CFoo"),</div></div></div><div class=""><div class=""><div class=""> ],</div></div></div><div class=""><div class=""><div class="">)</div></div></div></blockquote><div class=""><div class=""><div class=""><br class=""></div></div></div><div class="">The semantic of this is that Foo depends on a package CFoo that is merely a folder in the current repository (e.g., we do not need to clone it from somewhere else).</div><div class=""><br class=""></div><div class="">In my case CFoo would contain a module.map and a binary blob, but in the general case it is any arbitrary kind of package.</div><div class=""><br class=""></div><div class="">This solves my three problems since 1) There's only one repo, 2) The binary is located with repo-based paths, 3) You're linking against the particular CFoo distributed in the repository.</div><div class=""><br class=""></div><div class=""># Custom include paths</div><div class=""><br class=""></div><div class="">Another possibility goes like this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">let package = Package(</div></div><div class=""><div class=""> name: "Foo",</div></div><div class=""><div class=""> extraIncludePaths: ["CFoo"]</div></div><div class=""><div class="">)</div></div></blockquote><br class=""><div class="">The semantic of this is that we pass `-I CFoo` to swiftc (e.g. that is emitted into `other-args` of llbuild.yaml)</div><div class=""><br class=""></div><div class="">In my case CFoo contains a module.map and a binary blob, but in the general case it contains any kind of header path that a package may want to import.</div><div class=""><br class=""></div><div class="">There are certainly other possibilities besides these two, I'm just suggesting them because they seem straightforward based on my poking around in the sourcecode today.</div><div class=""><br class=""></div><div class="">I am happy to contrib either of these (or something else proposed) but would like to achieve consensus on a design instead of PRing by surprise.</div></body></html>