You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When building a package with SwiftPM, the package manager builds the Package.swift for each package in the complete hypothetical dependency tree of the root package: that is, it builds all the dependencies for all products defined in any Package.swift.
This can be demonstrated by considering the following three Package.swift files. The first one, for the root package:
If, from the directory containing the first Package.swift, you run swift build, the build will fail due to the error in leaf's Package.swift. This is despite the fact that leaf is not necessary to build head: head's only dependency is on products that do not depend on leaf.
Put another way, SwiftPM eagerly compiles the Package.swift for all possible dependencies of each package, rather than restricting itself only to the actual dependencies of each package. SwiftPM doesn't go so far as to actually compile each of the packages, so there is no issue with errors in the package themselves, but if for some reason the Package.swift generates warnings or errors then this will cause builds that appear to fail, while actually being quite capable of succeeding. This can happen for Package.swift's that require system dependencies that are not present, but which are not required for the actual build in question.
Please find attached a tarball that expands to a trio of repositories that demonstrate the issue.
The text was updated successfully, but these errors were encountered:
Attachment: Download
Environment
Swift 4
Additional Detail from JIRA
md5: 21bb328f0003af1c21ffa211feb59e6f
Issue Description:
When building a package with SwiftPM, the package manager builds the Package.swift for each package in the complete hypothetical dependency tree of the root package: that is, it builds all the dependencies for all products defined in any Package.swift.
This can be demonstrated by considering the following three Package.swift files. The first one, for the root package:
import PackageDescription
let package = Package(
{{ name: "head",}}
{{ products: [}}
{{ .executable(name: "head", targets: ["head"]),}}
{{ ],}}
{{ dependencies: [}}
{{ .package(url: "../middle", from: "1.0.0"),}}
{{ ],}}
{{ targets: [}}
{{ .target(name: "head", dependencies: ["MiddleSecond"]),}}
{{ ]}}
)
The second one, containing the declaration for the middle package:
import PackageDescription
let package = Package(
{{ name: "middle",}}
{{ products: [}}
{{ .library(name: "MiddleFirst", targets: ["MiddleFirst"]),}}
{{ .library(name: "MiddleSecond", targets: ["MiddleSecond"]),}}
{{ ],}}
{{ dependencies: [}}
{{ .package(url: "../leaf", from: "1.0.0"),}}
{{ ],}}
{{ targets: [}}
{{ .target(name: "MiddleFirst", dependencies: ["leaf"]),}}
{{ .target(name: "MiddleSecond"),}}
{{ ]}}
)
The third one, containing the leaf dependency:
import PackageDescription
let package = Package(
{{ name: "leaf",}}
{{ products: [}}
{{ .library(name: "leaf", targets: ["leaf"]),}}
{{ ],}}
{{ targets: [}}
{{ .target(name: "leaf")}}
{{ ]}}
)
invalidSyntax()
If, from the directory containing the first Package.swift, you run swift build, the build will fail due to the error in leaf's Package.swift. This is despite the fact that leaf is not necessary to build head: head's only dependency is on products that do not depend on leaf.
Put another way, SwiftPM eagerly compiles the Package.swift for all possible dependencies of each package, rather than restricting itself only to the actual dependencies of each package. SwiftPM doesn't go so far as to actually compile each of the packages, so there is no issue with errors in the package themselves, but if for some reason the Package.swift generates warnings or errors then this will cause builds that appear to fail, while actually being quite capable of succeeding. This can happen for Package.swift's that require system dependencies that are not present, but which are not required for the actual build in question.
Please find attached a tarball that expands to a trio of repositories that demonstrate the issue.
The text was updated successfully, but these errors were encountered: