Пути поиска Xcode для публичных заголовков в зависимостях

Я пытаюсь очистить некоторые из моих проектов, и одна из вещей, которые меня озадачивают, - это как обрабатывать файлы заголовков в статических библиотеках, которые я добавил как "зависимости проекта" (добавив сам файл проекта), Основная структура такова:


MyProject.xcodeproj
  Contrib
    thirdPartyLibrary.xcodeproj
  Classes
    MyClass1.h
    MyClass1.m
    ...

Теперь зависимости настроены и построены правильно, но как я могу указать публичные заголовки для "thirdPartyLibrary.xcodeproj", чтобы они находились на пути поиска при создании MyProject.xcodeproj. Прямо сейчас, у меня есть жестко закодированный каталог include в файле thirdPartyLibrary.xcodeproj, но, очевидно, это неудобно и не переносится. Я предполагаю, что, поскольку заголовки являются общедоступными и уже построены для некоторого временного местоположения в ~/Library (где также находится файл .a), существует четкий способ ссылки на этот каталог. Только.. как? Час Гуглинга оказался пустым, поэтому любая помощь очень ценится!

Ответ 1

Я думаю, что ваше решение достаточно и общепринятое. Один из альтернатив должен состоять в том, чтобы все заголовочные файлы находились под зонтичным каталогом, которые могут описывать интерфейс для использования библиотек с зависимыми данными и помещать их в ваш путь включения. Я вижу, что это похоже на /usr/include. Еще одна альтернатива, которую я никогда не пробовал лично, но, я думаю, будет работать над созданием ссылок на все заголовки третьейPartyLibrary из MyProject, чтобы они, как представляется, были членами MyProject. Вы сделали бы это, перетащив их из какого-либо места в MyProject и отменив выбор флажка, который говорит, чтобы скопировать их в каталог верхнего уровня проекта. С одной точки зрения это кажется мне осуществимым, потому что вы явно заявляете, что ваш проект зависит от этих конкретных классов, но он не несет прямой ответственности за их компиляцию.

Одна из вещей, о которых следует опасаться при решении этой проблемы, зависит от специфических для реализации деталей Xcode для автоматического поиска библиотек. В то же время это может показаться безобидным, но рабочие процессы, которые он использует для создания проектов, могут быть изменены с помощью обновлений и могут потенциально прервать ваш проект тонким и запутанным образом. Если они не определены в какой-либо документации, я бы принял какое-то влияние как совпадение и не имел смысла использовать ваш проект, если вы можете применить желаемое поведение другими способами. В конце концов, вам, возможно, придется определить соглашение, за которым вы следуете, или найти тот, который вы принимаете от кого-то другого. Поступая таким образом, вы можете быть уверены, что если ваше решение будет документировано и воспроизведено, любой разработчик (включая вас в будущем) может забрать его и продолжить, не спотыкаясь о нем, и что он будет стоять завет времени.

Ответ 2

Если я правильно понимаю, я считаю, что вы хотите добавить путь к файлу $(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 в моих настройках сборки проекта.

HEADER_SEARCH_PATHS = $(BUILT_PRODUCTS_DIR)/usr/local/include

Ваша ситуация может быть немного иной, но точный путь, который вы ищете, можно найти в Настройки сборки Xcode. Также вам может оказаться полезным добавить фазу запуска Script к вашей цели и отметить значения различных параметров во время сборки с помощью чего-то вроде:

echo "BUILT_PRODUCTS_DIR " $BUILT_PRODUCTS_DIR
echo "HEADER_SEARCH_PATHS " $HEADER_SEARCH_PATHS
echo "PUBLIC_HEADERS_FOLDER_PATH " $PUBLIC_HEADERS_FOLDER_PATH
.
.
.
etc.

Ответ 3

Способ, которым мы это делаем, заключается в том, чтобы перейти к настройкам целевого проекта для основного проекта и добавить:

User Header Search Path = "Contrib"

и проверьте, что он ищет рекурсивно. Мы не видим проблем с производительностью при поиске рекурсивно даже со многими (10-15 в некоторых проектах) зависимостями.