[swift-dev] Default deployment target for swiftc

[Tony Allevato]

I agree, the currently running OS seems like the right default here.
Progressive disclosure and ease of prototyping are good motivations here.
If I just want to quickly prototype something, I'm not going to be thinking
about choosing a minimum OS; I'm just going to write something using the
APIs that are available on my current one. If I decide to distribute that
later, *that's* when I'm going to start thinking about minimums (and adding
availability directives, if needed).

On Mon, Nov 27, 2017 at 4:53 PM William Dillon via swift-dev <
swift-dev at swift.org> wrote:

> It would be my assumption that it would build for the currently running
> OS.  It would be very confusing to me to have availability checks failing
> for an OS version lower that what I'm using.  I'm sure that I would be
> swearing for a few hours before I finally found the obscure documentation
> that said that it would compile for the oldest OS swift supports.
>
> Thanks for asking us! :)
>
> - Will
>
>
> On Nov 27, 2017, at 4:44 PM, Jordan Rose via swift-dev <
> swift-dev at swift.org> wrote:
>
> Hi, all. Consider the following command, as run on a Mac with an
> up-to-date Xcode installed:
>
> xcrun swiftc foo.swift
>
>
> The question: should this build for the *current running OS,* or *the
> oldest macOS Swift supports* (10.9)? You can always specify the
> deployment target OS version explicitly with the -target option, but what
> should the default behavior be?
>
> Some points to consider:
> - The deployment OS affects availability checks, which means that the
> command might succeed on one host but fail on another.
> - …but we already changed the default for the interpreter (`xcrun swift`)
> to be the current running OS in Swift 3.1 (Xcode 8.3, last spring).
> - Clang defaults to the current running OS (as of a few Xcodes ago, IIRC).
>
> Given these points, I'm inclined to change swiftc to default to building
> for the current running OS when no target is specified, but what do other
> people think?
>
> Note that this doesn't apply to projects built with either Xcode or the
> Swift Package Manager, both of which always explicitly provide a deployment
> target. Invoking swiftc directly and not providing -target means (1) you
> are definitely compiling for Mac (when run on a Mac), and (2) there's a
> good chance you don't plan to distribute what you just built, because until
> Swift lives in the OS, it has dependencies on your installed Swift
> toolchain (currently messily resolved with absolute rpaths). If you avoid
> this with -static-stdlib, you're giving up the ability to have dynamic
> libraries, because we didn't implement that properly.
>
> Thanks for your feedback!
> Jordan
>
> P.S. For Apple folks, this is rdar://problem/29948658.
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171128/4a870b73/attachment.html>