Add build configuration filters to build files and target dependencies (SE-0273 follow-up)

[dmhts]

This is the swift-build half of finishing the work proposed in SE-0273, following up on my forum thread. SE-0273 originally introduced platform-based conditional dependencies (.when(platforms:)). Configuration-based conditionals were part of the discussion at the time but never landed. This PR is the first of two steps to finally ship them. Step two will be the matching SwiftPM adoption.

When I posted on the forums, @owenv pointed out that mirroring the existing platform-filter mechanism would be the most scalable approach, so that's what this does. BuildConfigurationFilter is a sibling of PlatformFilter end-to-end: the filter type itself, the PIF wire format, the ProjectModel surfaces, every task-producer call site, the diagnostics.

What lands here

• New BuildConfigurationFilter type in SWBProtocol, SWBCore, SwiftBuild.ProjectModel, and the PIF builder in SWBProjectModel (one per layer, matching PlatformFilter).
• buildConfigurationFilters property on BuildFile and TargetDependency, with PIF serialization. The new "buildConfigurationFilters" key is optional in the loader, so existing PIFs still load fine.
• We check the filter everywhere we already check the platform filter: the filtering logic itself, dependency resolution, linkage, the header / TAPI file list / Swift package auto-embed paths, and the build-dependency-info that goes out to IDE clients.
• A new .buildConfigurationFilter exclusion reason with its own "Skipping … because its build configuration filter (…) does not match …" debug note, mirroring the platform-filter equivalent.

Scope rationale

The end goal of this work is per-configuration target dependencies in SwiftPM (the SE-0273 follow-up). swift-build's existing platform-filter mechanism already covers every build-file kind, not just target dependencies, so this PR mirrors it in full.

Source compatibility

addDependency, addLibrary, and addResourceFile in SWBProjectModel.PIFGenerationModel take buildConfigurationFilters: as a required parameter (no default) - same shape as platformFilters: on those methods. SwiftPM and Xcode call sites will need to pass buildConfigurationFilters: [] explicitly. If reviewers would rather skip that migration for downstream clients, I can default the parameter to [] in this PR.

addBuildFile overloads default buildConfigurationFilters: to []. Same shape as platformFilters: on those methods. Existing call sites for source / resource / framework files keep working unchanged.

Next step

A follow-up PR in swiftlang/swift-package-manager will add .when(configuration:) to SwiftPM's condition surface, translate it into the filter set, and route it through the existing addDependency(..., linkProduct: true) path. Once both PRs land we'll have parity with .when(platforms:) for build configurations.

[owenv]

Thanks,This approach looks fairly reasonable except for one major design decision to be made around package config overrides. note that the unimplemented parts of SE-0273 have expired since it's been >1 year since it was accepted though, so the changes will need to be re-proposed before it officially lands in SwiftPM.

[owenv]

Most of these tests look like they could just require a host SDK and run on linux/windows as well

[dmhts]

Good point. Adapted them to the host SDK, except the TAPI one. The package auto-embed test is the one I'm less sure about cross-platform, since framework embedding is fairly Apple-specific, so I'll keep an eye on it in CI and gate it back to macOS if it doesn't hold up.

[dmhts]

@owenv CI confirmed the concern about the auto-embed test, so I gated it back to macOS as planned. The source-filtering ones failed too, but for a fixable reason: under the host SDK they used .application, whose product type (com.apple.product-type.application) doesn't resolve outside Apple platforms. I switched those to .commandLineTool, which resolves everywhere, matching what platformFiltering_Linux does, and verified them passing in a Linux container, not just the macOS host. The same change should clear the Windows failures too.

So the final split:

• buildConfigurationFiltering_Debug/_Release: cross-platform on the host SDK via .commandLineTool.
• filteredPackageFrameworkExcludedFromAutoEmbed: macOS-only. On Linux the package framework builds to a .so and there's no bundle to embed into.
• filteredPublicHeaderExcludedFromTAPIFileList: macOS-only, since TAPI is Apple-only.

Could you kick off another CI run when you get a chance? Hopefully one of the last.

[dmhts]

Unrelated: while verifying this on Linux I noticed there's no doc on running the tests in a container beyond the .devcontainer config. Happy to add a short "running on Linux" section to the README as a separate PR if that'd be useful.

[owenv]

@swift-ci test

[dmhts]

@owenv could you please trigger another CI run?

[owenv]

@swift-ci test

[dmhts]

@owenv I brought the branch up to date with upstream: resolved a conflict in SettingsTests and adopted the new builtProductsDirSuffix(core:) signature it introduced, which caused the earlier test failures. Could you kick off another CI run when you get a chance?

[owenv]

@swift-ci test