Skip to content

Use executableTarget in generated new executable packages #3263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 24, 2021

Conversation

egorzhdan
Copy link
Contributor

Motivation:

Newly generated executable packages currently use .target(...) API for declaring the executable target, which seems to be deprecated since 5.4.

Modifications:

  • bumped swift-tools-version for new packages to 5.4
  • replaced .target call with .executableTarget for new executable packages

Result:

After this change swift package init --type executable generates a package which declares the executable target via the new .executableTarget(...) API.

@egorzhdan
Copy link
Contributor Author

@swift-ci please smoke test

@abertelrud
Copy link
Contributor

Thanks for the PR! This is a great change in the log run, but because 5.4 is very new, does it make sense for new packages to require it? New packages should still build without warning since they currently specify 5.3 manually.

@neonichu
Copy link
Contributor

I think in previous releases, we have updated the template to use the latest tools-version.

@tomerd
Copy link
Contributor

tomerd commented Feb 13, 2021

I think in previous releases, we have updated the template to use the latest tools-version.

this makes sense to me, ideally it's pinned to "current" and does not require manual changes and the unit tests catch if there are any issues with a newly minted packages.

@egorzhdan
Copy link
Contributor Author

Thanks for the feedback!

The recent releases like 5.3/5.2/5.1 indeed use the latest available tools-version, and this PR targets the 6.0 branch, so I thought it would be fine to increase it to 5.4.
But if it's too early, I can resubmit this patch some time later.

@abertelrud
Copy link
Contributor

The recent releases like 5.3/5.2/5.1 indeed use the latest available tools-version, and this PR targets the 6.0 branch, so I thought it would be fine to increase it to 5.4.

That makes sense to me — I didn't realize that there was precedent here.

@@ -15,7 +15,7 @@ import PackageModel
/// Create an initial template package.
public final class InitPackage {
/// The tool version to be used for new packages.
public static let newPackageToolsVersion = ToolsVersion(version: "5.3.0")
public static let newPackageToolsVersion = ToolsVersion(version: "5.4.0")
Copy link
Contributor

@tomerd tomerd Feb 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

given the other comments can we change this to the "current version", .i.e SwiftVersion.currentVersion and confirm we have unit tests to make sure it never broken (I believe we already do)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Yes, there is already a test that ensures the generated packages are buildable & contain the // swift-tools-version comment (WorkspaceTests/InitTests.swift)

@tomerd tomerd assigned yim-lee and unassigned yim-lee Feb 16, 2021
@egorzhdan
Copy link
Contributor Author

@swift-ci please smoke test

@tomerd
Copy link
Contributor

tomerd commented Feb 16, 2021

macOS CI broken due to swift-driver cc @artemcm

@tomerd tomerd added the next waiting for next merge window label Feb 16, 2021
@tomerd
Copy link
Contributor

tomerd commented Feb 16, 2021

@swift-ci please smoke test macOS

@tomerd tomerd merged commit aa681bd into swiftlang:main Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next waiting for next merge window
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants