Re: [swift-dev] Default deployment target for swiftc

[Chris Lattner via swift-dev]

+1

-Chris

> On Nov 28, 2017, at 10:36 AM, Tony Allevato via swift-dev 
>  wrote:
> 
> 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 
> > 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 > > 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@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Default deployment target for swiftc

[Greg Parker via swift-dev]

There should not be any availability checks required in the common 
fast-prototyping case, where your SDK version and your running OS version are 
the same. 

Availability checks are required when some API has changed since the OS version 
that is your deployment target. In the fast-prototyping scenario the SDK 
describes no OS versions newer than the default deployment target. Therefore no 
such API changes are possible.

As Tony said, if you subsequently set the deployment target to be older or 
build with the same deployment target using a newer SDK then you may need to 
write availability checks.


> On Nov 28, 2017, at 11:15 AM, William Dillon via swift-dev 
>  wrote:
> 
> I think you'll still have to write the availability checks, because Swift 
> will make you.  I think the fixit also tells you what you need for the API 
> you're trying to use.  The confusing thing will be, though, that it'll use 
> the fall-back path unless you explicitly set the target version.
> 
>> On Nov 28, 2017, at 10:36 AM, Tony Allevato via swift-dev 
>> > wrote:
>> 
>> 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 
>> > 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 >> > 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@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-dev 
>>> 
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing 

Re: [swift-dev] Default deployment target for swiftc

[Jordan Rose via swift-dev]

Thanks, all. Sounds like following Clang and the interpreter is the way to go. 
https://github.com/apple/swift/pull/13114

Jordan


> On Nov 27, 2017, at 16:44, Jordan Rose via swift-dev  
> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Default deployment target for swiftc

[William Dillon via swift-dev]

I think you'll still have to write the availability checks, because Swift will 
make you.  I think the fixit also tells you what you need for the API you're 
trying to use.  The confusing thing will be, though, that it'll use the 
fall-back path unless you explicitly set the target version.

> On Nov 28, 2017, at 10:36 AM, Tony Allevato via swift-dev 
>  wrote:
> 
> 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 
> > 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 > > 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@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Default deployment target for swiftc

[Tony Allevato via swift-dev]

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@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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Default deployment target for swiftc

[William Dillon via swift-dev]

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  
> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev