<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 7, 2017, at 12:34 AM, Cory Benfield <<a href="mailto:cbenfield@apple.com" class="">cbenfield@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; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 6 Nov 2017, at 20:25, Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">It’d be great to be able to stick an #include path and a linker flag string into Package.swift instead of creating empty c modules that just include system headers. right now this means you have to use a makefile (or up-arrow in the terminal to get the linker flags back) to compile Swift projects that depend on system libraries.<br class=""></div></div></div></div></div></blockquote><br class=""></div><div class="">While I don’t know that I want to be able to just shove include paths and linker flags into Package.swift, I do think some work should be done with Swift projects that want to link system libraries.</div><div class=""><br class=""></div><div class="">Right now as Kelvin notes you end up writing a ton of copy-paste Swift packages that all basically have the same form: a Package.swift that lists the name of the .pc file, a package name derived from that, and nothing else. Maybe, if you’re feeling generous, a brew() and/or apt() declaration.</div><div class=""><br class=""></div><div class="">This is sufficiently repetitious that it would actually be possible to write a service that dynamically generates these on the fly: that is, you could write a service that links libgit2 and that builds a git repo on the fly containing these details and serves it to you, such that you could do git clone <a href="https://buildaswiftsystempackage.com/icu-uc.git" class="">https://buildaswiftsystempackage.com/icu-uc.git</a> and would receive exactly this format for any .pc name.</div><div class=""><br class=""></div><div class="">Given that it’s so straightforward it’s probably worthwhile having SwiftPM grow the ability to synthesise these itself, rather than requiring users to write these identical modules every time.</div></div></div></blockquote><br class=""></div><div>I agree that this is an area where we should improve support. This is on my personal list of things to consider for this year, though you don't need to wait for me if you'd like to start hashing out a proposal on the list.</div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div class="">On Nov 6, 2017, at 12:25 PM, Kelvin Ma <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><div class=""><br class=""><div class="gmail_quote">On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="" style="word-wrap: break-word; line-break: after-white-space;"><div class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">– <b class="">Submodules</b></div><div class=""><br class=""></div><div class="">Can you elaborate on exactly what you'd like to see here? Offhand I don't recall seeing any feature requests in this area.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I think submodules means slightly different things to different people but to me i imagine something like “modules that get compiled together as a unit”, i.e., there are no ABI boundaries between submodules.</div></div></div></blockquote><div><br class=""></div>This sounds like a language feature, not a package-manager feature per-se (though we'd need to support it in the package manager).</div><div><br class=""><blockquote type="cite" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="" style="word-wrap: break-word; line-break: after-white-space;"><div class=""><div class=""><div class=""><div class="">– <b class="">Help us manage symbol versioning and availability</b></div><div class=""><br class=""></div><div class="">Can you elaborate on what you'd like to see here? <br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I only bring this up because there’s been a lot of talk about library evolution, and it is still easy for you to accidentally break your ABI in an unintended manner as nothing in the compiler really checks this. It’d be nice if the SPM took on a bigger role in checking ABI compatibility.</div></div></blockquote><div><br class=""></div>Swift packages are source-only, so I'm not sure that ABI is a concern right now, but unintended API breakage without a corresponding bump in major semantic version certainly is! We'd love to build tooling that can understand your package's API and make sure you're using versioning correctly (at least for Swift API, if not for other languages we support).<br class=""><br class=""><blockquote type="cite" class=""><div class="gmail_quote"><div class="">Something else I think will become important to have in the SPM is a better name conflict resolution system. Right now if you depend on two modules (even indirectly) that have the same name there’s really nothing you can do. The SPM should have something like an “import as” system where we can rebind a conflicting module to a new local name.</div></div></blockquote><div class=""><div class=""><div class="gmail_quote"><div class=""><br class=""></div></div></div></div></div><div><div class="gmail_quote"><div class="">Yeah, namespacing in general is something that's come up a number of times, but I think needs to be driven on the language side.</div><div class=""><br class=""></div><div class="">Thanks,</div></div></div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Rick</div><br class=""></body></html>