[SR-16060] Provide alternate way to pass SPM BuildConfiguration to packages

[gutley]

Previous ID	SR-16060
Radar	None
Original Reporter	@gutley
Type	Improvement

Additional Detail from JIRA

| | | |------------------|-----------------| |Votes | 0 | |Component/s | | |Labels | Improvement | |Assignee | None | |Priority | Medium | md5: cd464b2f75c04b1121f93c971240f602

Issue Description:

The issue explained here Annoying limitation of PackageDescription.BuildConfiguration means that unless the build Configuration specified in Xcode has "Debug" (or similar) in its name, it is not possible to use the following to pass a debug-only settings down to a package, nor to have the default "DEBUG" setting added to debug builds.

swiftSettings: [.define("ENABLE_SOMETHING", .when(configuration: .debug))]

Relying on the Build configuration's name as the sole way to determine debug vs release for packages seems a big limitation.

Instead I believe there should be another build setting in Xcode that can be used to specify what SPM BuildConfiguration to apply when building packages. The existence of such a setting would override the default name-based heuristics.

Being a normal build setting, this could be overridden at the project or target level and be settable in xcconfig files.

So a setting such as:

SWIFT_PACKAGE_MANAGER_BUILD_CONFIGURATION, with available options debug, release and default.

In default, Xcode falls back to using its heuristics.

In Xcode's build settings view, the "Resolved" column would show the actual one that will be used (debug or release), after applying any heuristics if the setting were left at (or set to) default.

It might also be useful to update the current default-heuristics to base the SPM BuildConfiguration on the optimization level of the current target too and choose debug when no optimization.

I don't think it is worth going overboard and allowing different configurations on a per-package basis.

Even without any changes, it would be good to document the current name-based heuristics fully.

[Fl0p]

Bump!

[AnthonyLatsis]

@gutley Have you reported this in the feedback assistant? If not, please do — the Swift project generally does not accept issues with Xcode.

@xedin This is an Xcode feature request, but I think handing it over to the SwiftPM folks to raise awareness is a better option than closing it out here.