A good program ape, will pay attention to every line of code he wrote, will see the warning to think about why, will try to eliminate the warning, the elimination of warning is an essential code cleanliness. So it’s a must for iOS developers to understand the types of warnings and turn on the necessary ones. Here are the Build Setting configuration options and Podfile configuration for warning.
Ios warning :The ios deployment target is set to x.x, but The range of supported deployment…. eliminate
Start the project and we’ll see this warning
/Users/linqiang/Documents/Project/ios-app/Pods/Pods.xcodeproj The iOS Simulator deployment target ‘IPHONEOS_DEPLOYMENT_TARGET’ is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.5.99.
Target ‘MJRefresh’ insert images here describing how they are generated? Take a closer look and you can see that this is the dependent third party library on targets in the POD project
The warning given. For example, my own Xcode is Xcode 12.5, as can be seen from the warning, the version support is 9.0~14.5, when the range is lower than the warning will be given.
Eliminate the warning
Add the following code at the bottom of your podfile
post_install do |installer| installer.pods_project.targets.each do |target| target.build_configurations.each do |config| If config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'].to_f < 9.0 config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '8.0' end end endCopy the code
There are a lot of warning signs in their comments when using third party libraries
For such warnings too many, directly affect our judgment of other content & warnings ⚠️, we want to treat bugs to eliminate warnings.
A workaround for the warning in the comments above
Build settings ->all – Documentation Comments – NO
Disallow all Warnings
Inhibit All Warnings Specifies whether to Inhibit All Warnings. The default is NO. If set to YES, you will not get any warning.
Pedantic Warnings
Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings: Pedantic Warnings The default is NO, which means NO prompt.
Equate a warning with an error
Treat Warnings as Errors, a common practice and code cleanliness fetish is to flag Warnings as Errors, thus interrupting the compilation process. This forces developers to fix these warnings to keep the code clean. This option defaults to NO, and setting it to YES equals a warning to an error. Sometimes you don’t want to be interrupted by a simple warning during development. You can set Debug to NO and Release to YES, and these warnings will be found during build Release.
We can also add -werror to Other C Flags to equal warnings to errors.
If you want to equate a certain type of warning to an error, you can write -werror =… . The following is an example:
Other C Flags
Other C Flags -werror, -wno-error =… , – Werror =… To achieve effects similar to the Treat Warnings as Errors option and more powerful extensions.
We can also add a special flag to Other C Flags to set the BOOL warning option in Build Setting.
The priority of Other C Flags is greater than that of a specific configuration. If the Unused Variable option in Apple LLVM 8.0-warning-all languages is set to YES, this type of Warning will be displayed. -wno-unused-variable -wno-unused-variable -wno-unused-variable -wno-unused-variable -wno-unused-variable -wno-unused-variable -wno-unused-variable -wno-unused-variable This type of warning will not be displayed at Other C Flags.
The following flag types are available in Other C Flags:
Associate warnings with errors
-werror, -wno-error =… , – Werror =… .
Turn on or off certain warnings
-W… Enable some warnings, such as -wunused-variable. -Wno-… Example Disable some warnings, such as -wno-unused -variable.
Open an alert group
-Wall isn’t all warnings. This set of warnings turns on warnings that the compiler developer has a high degree of confidence about the proposition that there is something wrong with the code you wrote. If your code gets a warning under this set of Settings, it’s basically a serious problem with your code. But at the same time, it’s not as if opening Wall is the answer, because Wall addresses only a few problems in the classic code base, so there are some fatal warnings that it doesn’t catch. But in any case, because Wall’s warnings provide highly credible and prioritized warnings, it should be a good practice to turn on this set of warnings for all projects (at least all new projects).
-Wextra as the name suggests, -Wextra group provides “extra” warnings. This group is almost as useful as the -wall group, but in some cases it is too harsh on the code. A very common example is -wsign-compare, which contains -wsign-compare. This warning flag turns on type checking for signed and unsigned comparisons, and raises a warning when one side of the comparator is signed and the other is unsigned. A lot of code doesn’t pay much attention to such comparisons, and most of the time it’s okay to compare signed and unsigned (although there can be fatal errors). It should be noted that -wextra and -wall are two warning groups independent of each other. Although some of the warning signs opened in them are repeated, there is no relationship between the two groups. If you want to use both, you must add them to Other C Flags.
-Weverything This is really all warning. However, most developers do not choose to use this logo because it contains warnings of possible bugs that are still under development. This flag is usually used by compiler developers for debugging purposes, and if you want to turn it on in your own projects, the warning will be so overwhelming that you’ll want to start hitting the wall.
Close the warning
Global shutdown
Find the corresponding warning option in build Setting and set it to NO. Build Setting Other C Flags -wno -… Logo.
File closure
Add the Compiler Flags corresponding to the Compile Source file of Build Phases to the Compiler Flags, such as -wno-unused-variable. The priority is as follows: Compile Source for Build Phases > Other C Flags for Build Setting >Build Setting The switch for warning is similar to that for file opening warning.
Turn off a warning on certain lines
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunused-variable"
int a;
#pragma clang diagnostic pop
Copy the codeUnused -variable warning will not appear if a is not used later.
reference
About alerts in iOS