There have been a few articles on the use of.xconfig files, such as this one, but after hands-on practice, I found that there are still some holes, which are documented here.

Build a new Configuration

This step is done in the “project-info-configuration” location. Click the “+” to build the “-” elimination. There is no problem.

Xcodebuild autopackage -configuration = xcodeBuild autopackage -configuration = xcodeBuild autopackage Debug and Release configurations are default for each project.

This Configuration is a complete summary of the Configuration for the same project.

Use the.xcconfig file

Creating a new file is easy; Xcode comes with the template. The next Configuration is in Configuration, such as First. Xcconfig for debug and Second. Xcconfig for Release, as shown in the following figure:

This is also an easy step. But when I started using it, my mind went in the wrong direction:

According to various articles, the contents of the configuration file (.xcconfig) overwrite the contents of the current Build Settings, so I thought that IF I wrote a configuration in the configuration file, the contents of the Build Settings would change accordingly.

For example, I’m in the Debug environment, and the corresponding is first.xcconfig, where I say:

//:configuration = Debug
OTHER_LDFLAGS = -Objcxxx

//:configuration = Release
OTHER_LDFLAGS = -Objcxxx

//:completeSettings = some
OTHER_LDFLAGS
Copy the code

It is the Other Linker Flags configuration, but the external Build Settings is the same.

I just got dizzy. What the hell is going on here.

There are two pits here

  1. The projectBuild SettingsWrite directly in the content will be prioritized, that is to say the Xcode has a default configuration file (yourAppName. Xcodeproj/project. Pbxproj), if you in directlyBuild SettingsTo edit is to write into it, for example, to modify itother linker flagGithub:

The Configuration in this file takes precedence over the Configuration in the.xcconfig file, so how do you use the Configuration in the.xcconfig file? Delete the configuration in Build Settings. The Command + delete.

  1. The xcConfig file is hard to write, because you can’t remember the configuration names, so you go to the actual Build Settings and copy it in the corresponding configuration item Command+C, so the content is like the above. I thought that the three sentences are used in different environments and do not disturb each other. OTHER_LDFLAGS = OTHER_LDFLAGS = OTHER_LDFLAGS = OTHER_LDFLAGS Empty, so it doesn’t show up even if you delete Build Settings. I thought the.xcconfig file didn’t work!

    So change it to OTHER_LDFLAGS = -objcxxx and there you have it.

Does the environment switch configuration also switch?

The advantage of using configuration files first is that after the environment switch, the configuration can be followed by a full set of switches, with.xcconfig acting as a package of related configurations.

And here’s another pit, or misinterpretation:

I thought that if you select something in Build Configuration, the content in Build Settings will change accordingly.

In fact, Build Settings is the same as it was before. Xcconfig: OTHER_LDFLAGS = -objc_first; Second. Xcconfig: OTHER_LDFLAGS = -objc_second;

Each Configuration will be divided into different configurations, such as Debug and Release, instead ofBuild SettingsThe whole thing is switched.

Or maybe it’s a structural problem, so that new contacts don’t know exactly what Xcode is and use different configurations for different situations.

The structure of the entire configuration

The actual structure looks like this:

  • The top layer isProject-info-ConfigurationThe configuration in
  • Then each configuration can have a different configuration file (.xcconfig), eachtargetA configuration file
  • Then there are many configuration items in each configuration file

But in theBuild SettingsIn the display, the structure is reversed:

  • The configuration file
  • Configuration items
  • Different Configuration

Also, macros

Preprocess Mcros is one of the Build Settings that can be used directly in code.

By defining different macros here, you can do different things with them in your code. For example, the default DEBUG macro is often used for conditional compilation.

$(XXX) can be used in Build Settings to refer to things in other configurations, so macros can be defined here and changed with other configurations.