Xcode пути поиска для публичных заголовков в зависимостях - PullRequest
11 голосов
/ 20 февраля 2011

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


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

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

Ответы [ 3 ]

3 голосов
/ 13 апреля 2011

Если я правильно понимаю, я считаю, что вы хотите добавить путь, содержащий $ (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 .Также может оказаться полезным добавить фазу сборки Run 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.
1 голос
/ 11 апреля 2011

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

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

0 голосов
/ 13 апреля 2011

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

User Header Search Path = "Contrib"

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...