[swift-evolution] [SPM] Roadmap?

[Kelvin Ma]

On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi,
>
> Is there any news about features that are willling to be integrated into
> SPM 5?
> Those I see the most relevant:
> - iOS support
> - Some kind of configuration/settings support (debug, release, ...)
>
> I'd like to hear about it from maintainers, especially if there's a
> priority order we should follow.
>
>
> Hi all,
>
> (CC-ing swift-build-dev, which is the SwiftPM-specific list and is the
> best way to get the SwiftPM core team's attention)
>
> The SwiftPM core team has been discussing our plans for SwiftPM 5, and
> expect to publish a roadmap of the features we're most likely to pursue
> this year. As always, we welcome proposals and contributions for features
> the community would most like to see.
>
> Regarding the specific features that have been mentioned in this thread:
>
> – *iOS support*
>
> I think that this will be best provided by native IDE integration.
> However, in the meantime, I'd welcome contributions to help improve Xcode's
> project generation support.
>
> – *Xcode integration*
>
> 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:
>
> 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.
>
>
> I'll note that as Xcode's new build system is still a "preview", 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't
> something I can discuss.
>
> – *Build settings and configuration support*
>
> The SwiftPM core team has done some work on a proposal for this, and we're
> looking forward to getting this into a publishable state and discussing it
> with the community.
>
> – *Submodules*
>
> Can you elaborate on exactly what you'd like to see here? Offhand I don't
> recall seeing any feature requests in this area.
>

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.


>
> – *Better support for including and linking C libraries*
>
> I'd also like to see this, and welcome proposals / contributions.
>

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.


>
> – *A swift test command that can execute arbitrary testing code*
>
> 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'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 "white box" (which
> needs -enable-testing) vs "black box" tests. It'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).
>

> – *Help us manage symbol versioning and availability*
>
> Can you elaborate on what you'd like to see here?
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171106/1ec44605/attachment.html>