iOS about the setting of Search Paths in Bulid Setting

Search Paths three heads:

• Framework Search Paths manages the path of the imported .framework

• Library Search Paths manages the path of imported .a

• Header Search Paths manages paths to imported header files

These three are often configured during development, so there are several issues that need to be clarified:

• Do you want to configure it?

• If so, what is the reason for configuring?

• How to configure?

The reason for writing the article is that when I refactored the project recently, I found that there are a lot of configurations under these three Search Paths , which is a bit annoying to look at. After checking the information, I deleted them all. The last three configuration items only retain $(inherited)the sum $(PROJECT_DIR), as shown in the figure:

During the running of the project, an error was reported, and a .a file could not be found, so the path of the .a was configured Library Search Pathsbelow , and the project ran successfully. So the question is, should we configure so many options? The following is an analysis of each in actual operation.

一、Library Search Paths

First delete a configuration item, run the project, and find that there is an error and cannot run, the prompt is as follows:

ld: library not found for -lzwlibIos
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It means that the .a library is not found, and it seems that it has to be configured. Here, only the .a path in the project needs to be configured. If it has been set $(inherited), there is no need to configure the path managed by cocoapods.

It can be seen that if there are .a files (except pods) in the project, they must be configured Library Search Paths. If you don't set at least one $(inherited), it won't matter anyway.

二、Framework Search Paths

Delete a configuration item in the same way, run the project, and find that there is an error and cannot run, the prompt is as follows:

ld: framework not found EquesBusiness
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It means that this .framework is not found, and it seems that it has to be configured. Similarly, only the .framework path in the project needs to be configured here. If it has been set $(inherited), there is no need to configure the path managed by cocoapods.

It can be seen that if there are .framework files (except pods) in the project, they must be configured Framework Search Paths. If you don't set at least one $(inherited), it won't matter anyway.

三、Header Search Paths

Delete a configuration item in the same way, run the project, and find that there is an error report that cannot be run. This time the location of the error report is different from the previous two. This error report occurs when the header file is imported, as shown in the figure:

Prompt content:

'***.framework/Headers/***.h' file not found

This is #importan imported problem, just modify the import method:

// 旧的引入方式
#import "EquesBusiness.framework/Headers/YKBusinessFramework.h"

// 新的引入方式
#import <EquesBusiness/YKBusinessFramework.h>

Then the project also ran successfully, let's take a look at the structure of this framework first. You can see the difference between the old and new introduction methods:

• #import ""became#import <>

• Missing Headers and .framework

I suddenly wanted to try this place, Header Search Pathsre-add this framework path, or use the new import method to see if there is any problem, the result is also very satisfactory, the project runs successfully.

To sum it up :

1. By importing, the path of framework #import ""must be added in . Header Search PathsAnd the path (the headers above) must be specified when it is introduced.

2. By #import <>importing, Header Search Pathsit doesn't matter whether it is configured or not, and you don't need to care about the path of .h in the framework, just <framework名/要引入的头文件.h>do it directly.

It can be seen that it is best to use import when introducing framework header files #import <>. While omitting configuration, it can also be regarded as a specification for encoding, which better distinguishes file attributes.

Four, finally

If you are interested, you can also learn about non-recursive, recursiveand $(inherited). It is convenient for you to better configure Search Paths. As for the choice non-recursive, recursiveI searched and everyone said that non-recursiveit will eventually change recursive, so just follow the system default non-recursivesettings.

As for the use of the path $(SRCROOT)or $(PROJECT_DIR)something else, I just drag it in and automatically generate it. The problem that can be solved so conveniently does not have to be so troublesome.