Как XCode узнает, в какой проект отлаживать, когда открыто несколько проектов одновременно? - PullRequest
4 голосов
/ 31 января 2011

TL; версия DR :

Этот вопрос возник из-за того, что у меня есть несколько фреймворков (которые я построил) и клиентский проект, который использует эти фреймворки. Теперь, когда я открываю клиентский проект и пытаюсь выполнить отладку в рамках, он не работает.

Однако, если у меня есть проект, связанный с открытой платформой, то отладка, кажется, работает (хотя есть некоторые странные проблемы с точками останова, которые я не вижу, запускаются).

Я посмотрел на документы Apple, и, возможно, ответ где-то там похоронен, но я не смог найти его в руководстве по отладке Xcode.

Длинная версия :

Причина, по которой этот вопрос важен для меня, заключается в том, что у меня и коллеги возникли разногласия по поводу того, как импортируются заголовки в создаваемые нами структуры.

У меня есть тенденция использовать заголовки фреймворка (с клиентскими приложениями) следующим образом:

#import "FrameworkA/HeaderA.h"
#import "FrameworkB/HeaderB.h"

С другой стороны, он предпочитает импортировать заголовки фреймворка (с клиентскими приложениями) следующим образом:

#import "HeaderA.h"
#import "HeaderB.h"

и указание путей поиска заголовка в целевом объекте клиентского приложения.

Еще более усложняет вопрос тот факт, что некоторые из этих структур имеют взаимозависимости. Например, FrameworkB имеет заголовки из FrameworkA, на которые ссылаются в его формате:

#import "HeaderA.h"

Его аргумент в пользу этого заключается в том, что отладка работает, только если мы импортируем заголовки таким образом. Мне кажется сомнительным, что существует связь между стилем импорта заголовка и отладкой, но я не совсем уверен, как XCode выбирает файл для ссылки во время отладки, поэтому возникает вопрос.

Заранее благодарим за любую помощь в этом вопросе.

1 Ответ

1 голос
/ 01 февраля 2011

вы добавляете ссылки на проект к цели и убедитесь, что Xcode знает, где найти символы отладки.

#import <FrameworkA/HeaderA.h>

это путь (для внутренних и внешних объявлений). причина? другой подход, скорее всего, вызовет проблемы по мере развития библиотек. дополнительная квалификация устраняет неоднозначность в любом случае (если, конечно, в вашем пути поиска нет двух FrameworkA/ s), лучше квалифицировать файл прямо сейчас, а не тогда, когда ваши клиенты говорят, что не могут использовать вашу библиотеку с другими библиотеками, или что они могут использовать их только в некоторых условиях. тогда вам нужно исправить проблемы и переадресовать (этот материал может происходить в неудобное время = p). это одна простая мера, чтобы убедиться, что вы разработали надежный интерфейс.

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

наконец, отладка сложных проектов в XCode может быть довольно ... давайте назовем это «проблематичным». Поэтому не ожидайте, что процесс отладки будет идеальным, даже если вы все настроили правильно. все больше причин для того, чтобы с самого начала интегрировать утверждения и модульные тесты в свой цикл разработки с помощью Xcode. Правда в том, что отладчик может быть бесполезен, как бы вы ни старались - это не новая проблема. надеюсь, LLDB улучшит наш опыт отладки.

удачи

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