[swift-build-dev] swiftpm macOS target override

[Keith Smiley]

The flag ordering change is now, so for now if you pass platform target
overrides from the command line, it can be newer than the hard coded value.

https://github.com/apple/swift-package-manager/pull/715

--
Keith Smiley

On 09/20, Daniel Dunbar wrote:
> > On Sep 20, 2016, at 2:44 PM, Keith Smiley via swift-build-dev <swift-build-dev at swift.org> wrote:
> >
> > Hey everyone,
> >
> > I noticed today that currently it doesn't seem possible to build to a macOS
> > target with a deployment target greater than 10.10 with swiftpm, since 10.10 is
> > currently hardcoded in the swiftpm source[0].
> >
> > This means that right now if you attempt to do something like:
> >
> > $ swift build --verbose -Xswiftc -target -Xswiftc x86_64-apple-macosx10.11
> >
> > You'll notice that this target is not sent to the first invocation of swiftc
> > (I'm not sure if this is a problem or not):
> >
> > ```
> > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc --driver-mode=swift -I /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/pm -L /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/pm -lPackageDescription -target x86_64-apple-macosx10.10 ...
> > ```
> >
> > And you'll see that the 10.11 target specification is overridden with the
> > default value when sent to swift-build-tool:
> >
> > ```
> > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-build-tool -f ... -v /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc ... -target x86_64-apple-macosx10.11 -target x86_64-apple-macosx10.10 ...
> > ```
> >
> > I have a few questions about this:
> >
>
> <reordered your questions :) />
>
> > Lastly if there has been any discussion about this previously I'd love to see it!
> >
>
> This is covered partly in https://bugs.swift.org/browse/SR-2535, but there hasn't really been any discussion about how to fix it, other than that we know it is very broken and needs to be dealt with.
>
> We haven't really tackled the problem of what is the "right" way to handle configurable compiler arguments in general (this also just came up on swift-dev w.r.t. custom C defines), and its.
>
> > - In the long term what's the plan for moving this out of being hard coded in
> >  swiftpm? If there is one, are there some starter tasks I could grab?
>
> Unfortunately, the honest answer is we don't really have one yet.
>
> The starter task is perhaps starting the discussion? We know we want to do something better than just arbitrary configurability through a "build settings" like model (which among other problems, doesn't compose well in a package-based world). We have some idea we want to have good modeling for flags which tie into important semantic concepts (like deployment targets), especially when they relate to the language, or the viability of particular packages or features. Beyond that, we don't have anything resembling a concrete design.
>
> > - In the short term would it make sense for us to reorder the user's args vs the
> >  default args in the few[1] uses[2] of these hardcoded args?
>
> I would be fine with that, I can't think of a reason not to.
>
>  - Daniel
>
> > [0]: https://github.com/apple/swift-package-manager/blob/57c5be1db1c1e12e089dff02241ffbce5722fb0e/Sources/Commands/UserToolchain.swift#L34-L39
> > [1]: https://github.com/apple/swift-package-manager/blob/64a4183e83f41e0c54791b03b86ab17f95fb93d4/Sources/Build/describe().swift#L41
> > [2]: https://github.com/apple/swift-package-manager/blob/64a4183e83f41e0c54791b03b86ab17f95fb93d4/Sources/Build/describe().swift#L76
> >
> >
> > Thanks for reading!
> >
> > --
> > Keith Smiley
> >
> > _______________________________________________
> > swift-build-dev mailing list
> > swift-build-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-build-dev
>