<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Our "Future Features" list does include "Support for Other Build Systems" (<a href="https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md#support-for-other-build-systems" class="">https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md#support-for-other-build-systems</a>), so long-term I think I'd like to see us develop a proposal for that as the solution to your problem here.</div></div></blockquote><div class=""><br class=""></div>If I'm not mistaken, one solution to this problem would be<div class=""><br class=""></div><div class="">* Add support for custom include paths</div><div class="">* Add a "preflight step" where a package can run a bash script as part of its build process</div><div class="">* Make the bash script run the external build system and point the include paths to a modulemap pointing to built products</div><div class=""><br class=""></div><div class="">I have an implementation + tests for all of these, <b class="">plus I've used them to package libdispatch</b>, in a private fork. That solution exists today.</div><div class=""><br class=""></div><div class="">I'm not saying it's the best solution. Would it make sense to sit down and spec out what is the "right way" to support an automake project like libdispatch? I would be more than happy to reimplement this some other way, if someone can explain what way that is.</div><div class=""><br class=""></div><div class="">I'm trying to minimize the scope of what I'm going to maintain myself in my fork, but being able to link C and Rust dependencies is non-optional for me, so I just went ahead and did it. I think it would be unfortunate if this feature is only available from me for awhile.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Your second proposal, for custom include paths, seems really specific to supporting pre-built binaries</div></div></blockquote><br class=""></div><div class="">Based on the above, this seems plainly false. I am using it to package libdispatch, which is a source package. There may be good reasons not to do this, but I don't think this argument is one.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 2, 2016, at 2:01 PM, Rick Ballard <<a href="mailto:rballard@apple.com" class="">rballard@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Drew,</div><div class=""><br class=""></div><div class="">This use case – facilitating packages that include pre-built binaries – is not one that we want to support right now. For the foreseeable future we'd really like to stick to source-based distribution, as discussed in <a href="https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md#source-based-distribution" class="">https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md#source-based-distribution</a>.</div><div class=""><br class=""></div><div class="">Your proposal for dependencies on subpaths within a repo is one that we might consider at some point independent of this problem, but we'd need a better driving reason to do so. (We've had some discussions internally about whether to enforce that each package lives at the top level of a repo, vs supporting repos that contains multiple packages, and, at least for now, I think we'd like to have a repo per package). Your second proposal, for custom include paths, seems really specific to supporting pre-built binaries, so I don't think that aligns with our goals.</div><div class=""><br class=""></div><div class="">Our "Future Features" list does include "Support for Other Build Systems" (<a href="https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md#support-for-other-build-systems" class="">https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md#support-for-other-build-systems</a>), so long-term I think I'd like to see us develop a proposal for that as the solution to your problem here.</div><div class=""><br class=""></div><div class="">So at the moment, I don't think I would want to accept a PR for either of these proposals. But I really appreciate your bringing this up.</div><div class=""><br class=""></div><div class="">Thank you,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Rick</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 25, 2015, at 8:22 AM, Drew Crawford via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Just to be clear...</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">If I PRed one or both of these, it would be rejected?</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">Sent from my iPhone</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">On Dec 25, 2015, at 9:36 AM, Max Howell <<a href="mailto:max.howell@apple.com" class="">max.howell@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class=""></div><div class="">This fulls under our "mixed targets" future plan.</div><div class=""><br class=""></div><div class="">For now I think you'll not be able to use swiftpm at all. Sorry :(</div><div class=""><br class="">On Dec 25, 2015, at 3:19 AM, Drew Crawford via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div 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 class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><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 class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><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: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-build-dev mailing list</span><br class=""><span class=""><a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a></span><br class=""></div></blockquote></div></blockquote><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=qz0eNO-2BnIaKwfHdqdSEoWDzK1gYoMlfMcRDuURe6g4mhuNxcZJd2nUtkM3NqaYAdKfekqLhu4VWc6jPyqXxM6xbWK0-2B5p3ZcbGob5jRkpQ45dJO-2BOp9WGFVNALjc5vsk5ayfMSU7TsrtQJBT3vTs6baGYi-2BPssHbErJ04MFs9m3iUZd9dOuv3O08AvyAnhqcRHiYny4iSPusuoVteK15dryFBqAZELkgr63tjSVq-2FhE-3D" alt="" width="1" height="1" border="0" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-build-dev mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-build-dev@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-build-dev@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>