Use global code coverage flag in swift package generate-xcodeproj
#2919
Conversation
There's a conflict between '--enable-code-coverage' in the top-level options and the same flag in the Xcode-project generation command. This uses the top-level flag (which is required for the build parameters, even though it's only ever used by `swift test`) for both purposes.
natecook1000
requested review from
abertelrud,
aciidgh,
friedbunny and
neonichu
as code owners
|
This should unblock moving to ArgumentParser version 0.3.1. |
|
Thanks for this fix! Do I understand correctly that the |
|
@swift-ci please test |
|
Right, the only user-facing change is that it adds the |
That seems fine to me, since Thanks! |
|
@swift-ci please smoke test |
|
Could we also change the version requirement in the manifest as part of this PR? |
|
Sure! We'll just need to coordinate landing with the other Swift project clients. I'll add a comment about that in the manifest. |
natecook1000
force-pushed
the
nate/code_coverage
branch
from
104191c to
90843d5
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please test self hosted |
|
@swift-ci Please smoke test self hosted |
natecook1000
force-pushed
the
nate/code_coverage
branch
from
90843d5 to
c743a2c
Compare
|
@swift-ci Please smoke test |
| @@ -263,7 +263,12 @@ if ProcessInfo.processInfo.environment["SWIFTPM_LLBUILD_FWK"] == nil { | |||
| if ProcessInfo.processInfo.environment["SWIFTCI_USE_LOCAL_DEPS"] == nil { | |||
| package.dependencies += [ | |||
| .package(url: "https://github.com/apple/swift-tools-support-core.git", .branch("master")), | |||
| .package(url: "https://github.com/apple/swift-argument-parser.git", .exact("0.3.0")), | |||
| // The 'swift-argument-parser' version declared here must match that | |||
There was a problem hiding this comment.
Slight nitpick here — it doesn't have to exactly match, but just be compatible. Since the dependency is "up to next minor", it means that all other dependencies have to resolve to a 0.3.x dependency. In general SwiftPM will pick the highest version that satisfies all the constrains, so it's fine for one package to specify "at least 0.3.0" and another to say "at least 0.3.2" and another to say "at least 0.3", as long as the package has a single tag that satisfies all requirements. So I think the working here would be that the version requirements have to be compatible, but they don't need to strictly match. It's only a problem if one of them starts to require "0.4.x", for example.
There's a conflict between '--enable-code-coverage' in the top-level options and the same flag in the Xcode-project generation command. This uses the top-level flag (which is required for the build parameters, even though it's only ever used by
swift test) for both purposes.