<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Just to be clear...</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">If I PRed one or both of these, it would be rejected?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I'm going to cook up some solution in any case, it's a question of whether I should be gearing up to distribute and maintain a long term fork. It's undesirable since it complicates upstreaming further work I do in my tree. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">But it will be unavoidable if I need a solution before you want to design it, which sounds like it may be the present situation. </div><div id="AppleMailSignature"><br>Sent from my iPhone</div><div><br>On Dec 25, 2015, at 9:36 AM, Max Howell <<a href="mailto:max.howell@apple.com">max.howell@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>This fulls under our "mixed targets" future plan.</div><div><br></div><div>For now I think you'll not be able to use swiftpm at all. Sorry :(</div><div><br>On Dec 25, 2015, at 3:19 AM, Drew Crawford via swift-build-dev <<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>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>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=cbMbdH1LnH6O78Q-2BHw3jtU8ikibH470Fh9meAJKpwSoR6Dp7FtuqYaEV4C9RawNf2ncqZHxy7-2Fr3spQxV0fCMIRRvE824kadSrr49o5DHiDpCvfmbMvOpUKIhbT2BvW-2BXGxzlS6xWTCcRn1qDsHvhF-2BXgExMGK7hKVpByw6dkCWN0dHQenyu5H6lU-2BWrbs5sVDg9u7ZAki0oXJ1TE8AOf0cfqYVSaXCXNqO14Hfqu-2Fk-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-build-dev mailing list</span><br><span><a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev">https://lists.swift.org/mailman/listinfo/swift-build-dev</a></span><br></div></blockquote></div></blockquote></body></html>