<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><div><div><div><br></div><div><div><blockquote type="cite"><div>On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_31741428449475102Apple-interchange-newline"><div><div dir="ltr"><div><div><div>Hi,<br><br></div>Is there any news about features that are willling to be integrated into SPM 5?</div><div>Those I see the most relevant:<br></div>- iOS support<br></div>- Some kind of configuration/settings support (debug, release, ...)<br><div><div><br></div><div>I&#39;d like to hear about it from <span class="m_31741428449475102gmail-_Tgc">maintainers, especially if there&#39;s a priority order we should follow.<br></span></div></div></div></div></blockquote></div></div></div></div><div><br></div></span><div>Hi all,<div><br></div><div>(CC-ing swift-build-dev, which is the SwiftPM-specific list and is the best way to get the SwiftPM core team&#39;s attention)<br><div><br></div><div><div>The SwiftPM core team has been discussing our plans for SwiftPM 5, and expect to publish a roadmap of the features we&#39;re most likely to pursue this year. As always, we welcome proposals and contributions for features the community would most like to see.</div><div><br></div><div>Regarding the specific features that have been mentioned in this thread:</div><div><br></div><div>– <b>iOS support</b></div><div><br></div><div>I think that this will be best provided by native IDE integration. However, in the meantime, I&#39;d welcome contributions to help improve Xcode&#39;s project generation support.</div><div><br></div><div>– <b>Xcode integration</b></div><div><br></div><div>I think this will be very important for widespread SwiftPM adoption by the Apple-platform developer community.  My previous comments on 2017/6/5 to this list are still the latest word on this:</div><div><br></div><div><blockquote type="cite">Xcode 9 lays the groundwork for first-class, native support in Xcode for Swift packages with the preview version of its new build system. This build system provides the flexibility and extensibility needed to allow Xcode to support new build models, such as Swift packages. Additionally, considerable work has gone into the SwiftPM library vended by the SwiftPM project, which will support integrating Swift packages into tools like Xcode.<br></blockquote><br></div><div>I&#39;ll note that as Xcode&#39;s new build system is still a &quot;preview&quot;, further work will be needed there before it replaces the old build system. As Xcode is not part of the open source project, forward-looking schedules aren&#39;t something I can discuss.</div><div><br></div><div>– <b>Build settings and configuration support</b></div><div><br></div><div>The SwiftPM core team has done some work on a proposal for this, and we&#39;re looking forward to getting this into a publishable state and discussing it with the community.</div><div><br></div><div>– <b>Submodules</b></div><div><br></div><div>Can you elaborate on exactly what you&#39;d like to see here? Offhand I don&#39;t recall seeing any feature requests in this area.</div></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div><div><br></div><div>– <b>Better support for including and linking C libraries</b></div><div><br></div><div>I&#39;d also like to see this, and welcome proposals / contributions. <br></div></div></div></div></div></blockquote><div><br></div><div>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></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div><div></div><div><br></div><div>– <b>A swift test command that can execute arbitrary testing code</b></div><div><br></div><div>As I recall, where the core team had left off on this was a discussion of what testability model were going to propose for SwiftPM (specifically, handling Swift&#39;s -enable-testing flag when needed, but minimizing unnecessary rebuilds from using that flag vs. having it off for release builds). IIRC, we were considering explicitly modeling &quot;white box&quot; (which needs -enable-testing) vs &quot;black box&quot; tests. It&#39;s been a little while since we last discussed this topic, so if anyone wants this urgently, feel free to start a public conversation about this. Any discussion of this should also involve the XCTest developers (via swift-corelibs-dev).</div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div><div><br></div><div>– <b>Help us manage symbol versioning and availability</b></div><div><br></div><div>Can you elaborate on what you&#39;d like to see here? <br></div></div></div></div></div></blockquote><div><br></div><div>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><br></div><div>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.<br></div></div></div></div>