![]() ![]() By declaring boolean values for several Xcode version tests: For this I am also leaning on an example I found in the WebKit sources. Each time you expand the contents of a $() construct, you end up with text that combines with the adjacent text to yield either a new build setting name, or the final value for a setting.įinally, let’s apply a similar trick to the question of whether we’re running Xcode 15 or later. You can make sense of these exotic uses of nested build settings by slowly walking through the expansion, from the inside out. This expands to $( NOT_YES) which in turn expands to NO. SHOULDNT_SUPPRESS = $(NOT_$(SHOULD_SUPPRESS)) NOT_ equals YES? What does it meeeeaaan? It only makes since when you consider what happens when you combine NOT_ with another build setting that is defined as a boolean value: For example, here’s a cool technique I learned from the WebKit project: The simple ability to nest build settings leads to a huge variety of clever tricks that allow you to impose a kind of declarative logic to settings. ![]() Obviously, hard-coding SHOULD_SUPPRESS to YES as we did above isn’t going to solve the problem, because these configuration settings will cause the incompatible linker parameter to be passed on Xcode 14 and earlier. For example, if you were to change the value of SHOULD_SUPPRESS to NO, you would see the “Other Linker Flags” value change to empty in Xcode. As you edit and save the file, Xcode updates the derived build settings in real time so you can check your work. Side note: when editing Xcode configuration files, keep one editor pane open to the configuration file, and one pane open to the Xcode build settings interface, focused on a project or target that depends on the configuration file. If SHOULD_SUPPRESS is NO, or any other value, then the expansion will lead to an undefined build setting, and thus will substitute an empty value. Here, the final value for OTHER_LD_FLAGS will only include the specified flags if the SHOULD_SUPPRESS build setting is YES, because expanding SHOULD_SUPPRESS yields the build setting SUPPRESS_WARNING_FLAGS_YES. SUPPRESS_WARNING_FLAGS_YES = -Wl,-no_warn_duplicate_libraries OTHER_LDFLAGS = $(SUPPRESS_WARNING_FLAGS_$(SHOULD_SUPPRESS)) ![]() Even more powerfully, you can nest build settings so that the value of one build setting is used to construct the name of another: These configuration directives have the same effect as the single-line definition above, because Xcode expands the SUPPRESS_WARNING_FLAGS setting and uses the result when setting the value of OTHER_LDFLAGS. SUPPRESS_WARNING_FLAGS = -Wl,-no_warn_duplicate_libraries ![]() OTHER_LDFLAGS = $(SUPPRESS_WARNING_FLAGS) The key to applying this technique is understanding that build settings can themselves be defined in terms of other build settings. The examples below will use the declarative format used by these files. Technically this technique could be used in Xcode’s build settings editor, but because of the complexity of variable definitions, it’s a lot easier (not to mention easier to manage with source control) if you declare such settings in an Xcode configuration file. There’s no straightforward way to avoid this problem, but Xcode build settings offer a sophisticated (albeit brain-bendingly obtuse) mechanism for varying the value of a build setting based on arbitrary conditions. (Maybe more correctly, depending on the version of the linker, but for this example we’ll focus on varying based on Xcode version). What we want to do if the project will continue to be built by both older and newer versions of Xcode, is to effectively derive a different value for OTHER_LDFLAGS depending on the version of Xcode itself. This simple declaration will address the problem on Xcode 15, but on Xcode 14 and earlier it will cause a link error because the old linker doesn’t recognize the argument. OTHER_LDFLAGS = -Wl,-no_warn_duplicate_libraries In it, I shared that the warning can be effectively disabled by passing a suitable argument to the linker: In the previous post, I described a problematic warning introduced by the new linker in Xcode 15. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |