依赖项中公共标头的 Xcode 搜索路径
我正在尝试清理我的一些项目，令我困惑的事情之一是如何处理我添加为“项目依赖项”的静态库中的头文件（通过添加项目文件本身）。基本结构是这样的：
MyProject.xcodeproj
Contrib
thirdPartyLibrary.xcodeproj
Classes
MyClass1.h
MyClass1.m
...
现在，依赖项都已正确设置和构建，但是如何指定“thirdPartyLibrary.xcodeproj”的公共标头，以便它们在构建 MyProject.xcodeproj 时位于搜索路径上。现在，我已经在thirdPartyLibrary.xcodeproj中硬编码了include目录，但显然这是笨拙且不可移植的。我认为，由于标头是公共的，并且已经构建到 ~/Library 中的某个临时位置（.a 文件也在其中），因此有一种巧妙的方法来引用该目录。只是..如何？一个小时的谷歌搜索结果一片空白，因此非常感谢任何帮助！
I am trying to clean up some of my projects, and one of the things that are puzzling me is how to deal with header files in static libraries that I have added as "project dependencies" (by adding the project file itself). The basic structure is like this:
MyProject.xcodeproj
Contrib
thirdPartyLibrary.xcodeproj
Classes
MyClass1.h
MyClass1.m
...
Now, the dependencies are all set up and built correctly, but how can I specify the public headers for "thirdPartyLibrary.xcodeproj" so that they are on the search path when building MyProject.xcodeproj. Right now, I have hard-coded the include directory in the thirdPartyLibrary.xcodeproj, but obviously this is clumsy and non-portable. I assume that, since the headers are public and already built to some temporary location in ~/Library (where the .a file goes as well), there is a neat way to reference this directory. Only.. how? An hour of Googling turned up blank, so any help is greatly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果我理解正确，我相信您想要将包含 $(BUILT_PRODUCTS_DIR) 的路径添加到项目构建设置中的 HEADER_SEARCH_PATHS 中。
作为示例，我采用了一个包含静态库的现有 iOS 项目，该静态库仅按照您描述的方式包含，并将库头文件设置为公共。我还注意到，该项目的 PUBLIC_HEADERS_FOLDER_PATH 设置为“/usr/local/include”，并且当父项目构建依赖项目时，这些文件将复制到 $(BUILT_PRODUCTS_DIR)/usr/local/include 。因此，解决方案是将 $(BUILT_PRODUCTS_DIR)/usr/local/include 添加到项目构建设置中的 HEADER_SEARCH_PATHS 中。
您的情况可能略有不同，但您寻找的确切路径可能可以在 Xcode 的构建设置。此外，您可能会发现将运行脚本构建阶段添加到目标并在构建时记下各种设置的值很有帮助，例如：
If I understand correctly, I believe you want to add a path containing $(BUILT_PRODUCTS_DIR) to the HEADER_SEARCH_PATHS in your projects build settings.
As an example, I took an existing iOS project which contains a static library, which is included just in the way you describe, and set the libraries header files to public. I also noted that the PUBLIC_HEADERS_FOLDER_PATH for this project was set to "/usr/local/include" and these files are copied to $(BUILT_PRODUCTS_DIR)/usr/local/include when the parent project builds the dependent project. So, the solution was to add $(BUILT_PRODUCTS_DIR)/usr/local/include to HEADER_SEARCH_PATHS in my project's build settings.
Your situation may be slightly different but the exact path your looking for can probably be found in Xcode's build settings. Also you may find it helpful to add a Run Script build phase to your target and note the values of various settings at build time with something like:
我认为你的解决方案是足够的并且是普遍接受的。一种替代方法是将所有头文件都放在一个伞目录下，该目录可以描述使用依赖库的接口并将其放入包含路径中。我认为这与 /usr/include 类似。我从未亲自尝试过，但我认为可行的另一种选择是从 MyProject 创建对 thirdPartyLibrary 的所有标头的引用，以便它们看起来是我的项目。您可以通过将它们从某个位置拖到MyProject中，然后取消选择将它们复制到项目顶级目录中的复选框来完成此操作。从一个角度来看，这对我来说似乎是可行的，因为就好像您明确声明您的项目依赖于这些特定的类，但它并不直接负责编译它们。
解决此问题时需要注意的一件事是依赖于 Xcode 的实现特定细节来自动定位库。与此同时，这样做可能看起来无害，但它用于构建项目的工作流程可能会随着更新而改变，并且可能会以微妙和令人困惑的方式破坏您的项目。如果它们在某些文档中没有明确定义，那么当您可以通过其他方式强制执行所需的行为时，我会将任何效果视为巧合，并且不值得在您的项目中利用。最后，您可能必须定义一个您遵循的约定，或者找到一个您从其他人那里采用的约定。通过这样做，您可以放心，如果您的解决方案已记录并且可重现，则任何开发人员（包括将来的您自己）都可以拿起它并继续操作，而不会被它绊倒，并且它将经受时间的考验。
I think that your solution is sufficient and a generally accepted one. One alternative would be to have all header files located under an umbrella directory that can describe the interface to using the depended-on libraries and put that in your include path. I see this as being similar to /usr/include. Another alternative that I have never personally tried, but I think would work would be to create references to all the headers of thirdPartyLibrary from MyProject so that they appear to be members of the MyProject. You would do this by dragging them from some location into MyProject, and then deselecting the checkbox that says to copy them into the project's top level directory. From one perspective this seems feasible to me because it is as if you are explicitly declaring that your project depends on those specific classes, but it is not directly responsible for compiling them.
One of the things to be wary of when addressing this issue is depending on implementation-specific details of Xcode for locating libraries automatically. Doing so may seem innocuous in the meantime but the workflows that it uses to build projects are subject to change with updates and could potentially break your project in subtle and confusing ways. If they are not well-defined in some documentation, I would take any effect as being coincidental and not worth leveraging in your project when you can enforce the desired behavior by some other means. In the end, you may have to define a convention that you follow or find one that you adopt from someone else. By doing so, you can rest assured that if your solution is documented and reproducible, any developer (including yourself in the future) can pick it up and proceed without tripping over it, and that it will stand the testament of time.
我们这样做的方法是进入主项目的构建目标设置并添加：
并检查它是否递归搜索。即使有许多（在某些项目中为 10-15 个）依赖项，我们也没有看到递归搜索的性能问题。
The way we do it is to go into build target settings for the main project and add:
and check that it searches recursively. We don't see performance problems with searching recursively even with many (10-15 in some projects) dependencies.