release after selecting the build configuration for the SPM package. In addition to the DEBUG flag, Xcode automatically selects the architecture to be compiled for a package based on. Compilation architecture and Apple Silicon
to set different bundle ids or app names for different environments), it may be an option to use multiple schemes and configure them with the appropriate environment variables to to differentiate between them. It is safer to just use the default Debug and Release Build Configuration, and when more environments are needed (e.g. These rules are written in the Xcode build toolchain, they are not open source, and there is no documentation on the matter, so they are subject to change in the future. To get SPM to work as intended, you must change the name of the Build Configuration in Xcode back to, say, Debug_Testing. When you painstakingly configure a Testing build configuration for your project with the intention of running tests exclusively, you find that the Swift packages compiled under this configuration are optimized and stripped of testable support. Xcode has chosen to be “empirical” and presumptuous here, and when SPM is used in Xcode, the name Custom Build Configuration becomes a joke. release as the compilation configuration. For example, the default Release, as well as things like Dev, Testing, Staging, Prod, Beta, QA, CI, etc., all use. For example, the default Debug, as well as Development, Debug_Testing, _development_, Not_DEBUG, and hello development are listed here. If the name contains Debug or Development (case-insensitive), then Xcode will use.Specifically, the rules found for now are. In the Xcode environment, Xcode selects the build configuration used for SPM packages based on the name of the Build Configuration. debug to build SPM packages, it “automatically” passes in DEBUG according to Xcode’s general build conditions. Determination based on Build Configuration Xcode will respect these settings when the user compiles your package using Xcode. If a long-term solution is needed, consider wrapping the required external packages again yourself: create a new Swift package that depends on these external packages, and then add the appropriate swiftSettings when exposing them.Īs package maintainers, if we use compile conditions other than DEBUG in our packages, it is best to add them in Package.swift accordingly. If you just need to temporarily pass in a compile condition, you can convert it to a local package by convert it to a local package and then add swiftSettings to it by doing something similar to the above. + swiftSettings: įor external packages that are added directly from the git repository, the contents are locked by default.
#Xcode project build settings code
This allows us to use code like the following to compile different content at Debug and Release time. In SWIFT_ACTIVE_COMPILATION_CONDITIONS, Debug Configuration predefines the DEBUG condition. In Xcode, when creating a project we are automatically given two Build Configuration: Debug and Release. Compile conditions in Xcode and SPM Default DEBUG build conditions Hopefully, future versions of Xcode and SPM will be improved.įor some examples in the text, you can find the source code here. Right now (October 2022) there is no particularly good way to map the Build Configuration in Xcode to the SPM build environment. This automatic selection may cause problems when using a custom Build Configuration in Xcode other than the default “Debug” and “Release”. Currently, when using Swift Package Manager packages in Xcode, SPM compiles the package with reference to the name of the Build Configuration and automatically selects whether to compile with debug or release, which determines the compilation flag like DEBUG and This determines the architecture of the final binary.
0 kommentar(er)
