4/16/2023 0 Comments Xcode build settings![]() ![]() Don’t be afraid to jump into your project’s build settings, and learn what they do. These simple examples demostrate the rules, but in real life things get much more complicated. The leftmost values win out due to precedence rules.Īn example using precedence. So, the same cells called out above now have the values XcPb and Tf, respectively. The screenshot below shows essentially the same setup as the one used to demostrate inheritance–the difference being that there’s no inheritance! Each cell has the same value as its counterpart in the inheritance-based version, with the $(inherited) selector removed. The linear precedence progression for build settings. With “Levels” selected in the Build Settings editor, precedence flows from right to left. An easy rule of thumb is to remember that settings defined in Xcode’s Build Settings editor always override the settings from any Xcconfig set for that same level. It’s a simple linear progression, starting from Xcode defaults down to Target-level. Precedence governs what settings can override those from other levels. Note that in this example, I purposely left $(inherited) off of the Xcconfig version of the top-Project-level setting, so as not to bring a bunch of noise into the example of the architectures list repeating over and over. When you look at the Resolved column, you can see how inheritance has propogated values down the line. For instance, the Xcconfig version of the Project-level macOS-specific setting is defined as $(inherited) XcPb, and the Build Settings editor version of the Target-level iOS-specific setting is defined as $(inherited) Tf. Each cell in the matrix defines just one value after inheriting. In the below screenshot, you can see some build settings that have been defined in both the Build Settings editor and Xcconfig files, with settings defined at top-, configuration- and platform-levels. The acyclic inheritance graph for build settings. Also keep in mind that each level in Xcode’s Build Settings editor inherits from the same setting in the corresponding Xcconfig. I think of the first trunk as linear, and the second and third I think of as transposable from Project- to Target-level: each level of the Project trunk influences its dual in the Target trunk. Target-level Platform and Configuration settings can inherit from two parents, as seen in the diagram, forming an acyclic graph. There are three main inheritance “trunks” to consider: The special selector $(inherited) brings in all settings resolved at the next highest level in the build setting graph. As a concrete example, Cocoapods will inject Xcconfigs into your project, which can be inadvertently overridden in the Target column of the Build Settings editor. Inheritance and precedence have their own rules in Xcode, and the complex relationships arising from all the composition methods make it tough to confidently change a setting without inadvertently propogating unwanted changes elsewhere. Xcode projects have Configurations defining entirely parallel sets of settings. ![]() Settings can be $(inherited) from multiple levels of granularity and overridden by target precedence. Dynamic setting expansion and platform selectors enables automatic resolution of settings based on environment or target details. Much of Xcode’s build system’s flexibility comes from composition–you can use both Xcconfigs and the Build Settings area, and #include Xcconfigs into others. You can find similar repos on GitHub, and I’ve even find a nice tool to extract Xcconfigs from Xcode projects. While I was at Fabric, we open sourced our collection of Xcconfigs: FABConfig. Some great articles exist that detail the build settings Xcode offers and ways to keep your ecosystem consistent and maintainable. With a sufficiently complicated product family, build pipeline and artifact/dependency graph, maintaining the build system can become a full time job. Xcode’s configuration system is daunting in its power and flexibility, and anyways it provides you with a good enough set of defaults and migrates you on new releases to keep you running correctly.Ī small toy app might get by this way, but serious projects need to pay careful attention to how they build their products. I had plenty to focus on learning the Cocoa APIs. For probably the first year or two I developed apps for iOS, I stayed as far away from the build settings area as I could. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |