These are Andrew McKnight's notes from his presentation on xcconfig files at the April 14, 2016, meeting:

Multiplatform targets

• • We have projects with many shared libraries, meaning many targets

  • We had many libraries with a target per platform (leading to many targets in the Xcode picker)

  • Can be tough to know which one to link as a dependency: https://twitter.com/NachoSoto/status/641806595278540800

  • build settings are duplicated and diverge easily across targets building the same product for each platform (especially if you use xcode's GUI editing)

we combined the platform-specific targets into one combined target

• • Most build settings have platform specifiers

  • Conditional compilation in code based on TARGET_OS_...

Benefits of using xcconfigs

• • consistent settings across multiple projects via sharing

  • Undo/redo support

  • commenting

  • less changes to project files

  • xcode find/replace works

  • better diffs

    • • filenames make it more obvious which target is changing

  • composable using #include

  • experiment with settings using the "Build Settings" pane in Xcode GUI

  • dynamic composition of settings

Notes:

• • we don't use

    • //:configuration = Debug <name-of-setting> = <debug-value> //:configuration = Release <name-of-setting> = <release-value> //:configuration = some <name-of-setting> = <shared-value>

    • instead we use

    • <name-of-setting>_iphoneos <name-of-setting>_iphonesimulator <name-of-setting> = $(<name-of-setting>_$(PLATFORM_NAME))

  • include paths get screwed up. e.g., we use this repo as a submodule, and if I forget to pull the submodule dependency, the includes in the dependee's xcconfigs point to files that aren't there. if I try to build, xcode helpfully warns that it couldn't find the file. if I pull the submodule dependency, however, the warning persists and the settings don't resolve, even after cleaning. There are two ways to fix it:

    • • modify the include path, and then set it back to what it was. Apparently, marking the file as dirty is the only way to get the config preprocessor to do another pass

      • quit xcode

      • (TODO: add radar link)

  • cocoapods injects their own xcconfigs, be careful not to overwrite their settings

    • • in most cases, you can specify a globel sdk specifier:

        • <setting-name>[sdk=*] = $(inherited) <my other settings...>

  • urls or other things with double slashes are treated as comments

    • • define another constant called SLASH that you can dynamically expand with $(SLASH)$(SLASH)?

FABConfig

• • we've collected our shared configs we use across our internally shared libraries, kit products and applications at https://github.com/twitter-fabric/FABConfig