Switching swift build -c release and swift test -c release always requires full-rebuilding

[kateinoigakukun]

Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc?

• Confirmed reproduction steps with SwiftPM CLI. The description text must include reproduction steps with either of command-line SwiftPM commands, swift build, swift test, swift package etc.

Description

As @dschaefer2 shared his concerns about build time, interleaving swift build -c release and swift test -c release executions require full-rebuilding for every execution because they switch -enable-testing driver option.

Expected behavior

#8025 (comment)

I think we have three options:

1. Keep the current behavior
   • Changing testability always requires full rebuilding
2. Have separate build description and object directory for with/without testability, not to overwrite artifacts
   • Changing testability requires full rebuilding only for the first time
   • Need non-trivial refactoring in SwiftPM because we assume a pair of build description and object directory corresponds to a configuration.
     • Or internally introduce [debug, debug-test, release, release-test] configurations
   • Double disk footprint if switching testability even once
3. Always build with -enable-testing
   • Changing testability never requires full rebuilding
   • Sacrifice runtime performance and code size in release mode

Actual behavior

$ swift build -c release -v 2>&1 | grep "/release/Example.build/Example.swift.o"
$ swift test -c release -v 2>&1 | grep "/release/Example.build/Example.swift.o"
$ swift build -c release -v 2>&1 | grep "/release/Example.build/Example.swift.o"
$ swift test -c release -v 2>&1 | grep "/release/Example.build/Example.swift.o"
...

You can see frontend invocation every time.

Steps to reproduce

No response

Swift Package Manager version/commit hash

58f9aa4

Swift & OS version (output of swift --version ; uname -a)

No response

[rauhul]

I brought this up here: https://forums.swift.org/t/pitch-restrict-testability-to-direct-in-package-source-module-dependencies-of-test-targets/73921

its really annoying and kills my productivity. I think adding "debug-test" / "release-test" is an ok short term option, but I think we need to be smarter about where/when -enable-testability is passed

[dschaefer2]

I'm wondering if my Windows fix for static/dynamic, which adds build rules for both and the consumers depend on the one they want, would apply here. Add two build rules for testable/not-testable, and let the tests depend on the testable ones.

[kateinoigakukun]

@dschaefer2 That approach totally sounds reasonable to me. So considering @rauhul's case, I suggest a change to add rules for both with/without testability only for direct dependencies of test targets and make test targets depend on testable rules.