XCode 4: статический анализ файлов заголовков

#xcode #clang

#xcode #clang

Вопрос:

У меня есть проект на C (в стиле GNU, с Makefile), и я хотел бы использовать XCode в качестве своей IDE, поскольку я хотел бы использовать функциональность Clang для автозаполнения и обнаружения проблем в реальном времени.

Для этого я создал новый проект -> Инструмент командной строки, а затем просто импортировал все свои файлы. Если я продолжу и отредактирую файл .cpp, XCode обнаружит текущие проблемы (выдает ошибку, если я пишу фиктивный код). Однако то же самое не работает для моих файлов .h. Интересно, что, похоже, это сработает, если я #включу эти файлы заголовков в один из моих файлов .cpp.

Как я могу решить эту проблему, не включая файлы заголовков из исходных файлов? Кроме того, я не уверен, что этот способ создания проекта (инструмент командной строки) является правильным. Я действительно хочу использовать XCode только для автозаполнения и обнаружения проблем, я не хочу создавать его через XCode (достаточно запустить «make»).

Ответ №1:

Просто создайте файл «перевода» для вашего проекта. В основном это будет файл .c, .cpp, .m и т. Д., Который включает заголовки, которые вы хотите проиндексировать.

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

Xcode 4.0 сделал это так, как вы хотите (в основном, все было проиндексировано на основе настроек сборки текущего проекта), но это было глючно и совершенно непригодно для использования в нетривиальных проектах и особенно проектах с разными настройками сборки. Например: он применит заголовок префикса неправильного проекта или не будет знать, как правильно построить график включения, чтобы он просто выдавал ошибки по всему заголовку (в некоторых случаях).

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

Если вам действительно не нравится файл перевода, вы можете вернуться к Xcode 4.0 или попробовать macvim’s clang_complete.