Почему Xcode 6 неправильно включает путь пользователя до пути к системе?

Я пытаюсь создать проект, который я сделал для Windows, Visual Studio под OSX, используя Xcode 6.1.1.Почему Xcode 6 неправильно включает путь пользователя до пути к системе?

У меня проблема с файлом, который должен содержать #include <string.h>. Однако в той же папке, что и файл, который делает это, есть файл, который называется string.h.

В моем проекте Visual Studio это все еще разрешает файл, сначала просматриваются системные пути.

В проекте Xcode я позаботился о том, чтобы настроить свои собственные пути в разделе «Пути поиска заголовка пользователя» - Xcode развернуть на правильный путь. Я также установить «Всегда поиск путей пользователя» на нет - что в соответствии с Docs говорит о том, что системные пути следует искать первый: https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW110

Но все же #include <string.h>, кажется, следует рассматривать как #include "string.h" по некоторым причинам.

Конфигурация определена в проекте, и я убедился, что цели не переопределяют это.

Это какой-то предмет Xcode/OSX, в котором система включает <> сначала поиск пути к файлу вложения?

Search path config

Мой местный string.h файл находится в ruby/api/string.h относительно включения пути в моей User Header Search Path.

Результаты https://gist.github.com/thomthom/034b539bede38dd68261: https://gist.github.com/thomthom/034b539bede38dd68261

источник

2015-03-03 thomthom

Попробуйте использовать '' #import возможно, или переименовать файл 'string.h' в вашем проекте к чему-то другому. '<>' vs '" "' обычно указывает стандартный путь к базе данных или путь к заголовку пользователя. –

Не '# import' объект Objective C? И хотя переименование будет работать вокруг - это кажется мне неправильным поведением, и я предпочел бы найти источник проблемы, а не переименовывать кучу файлов. – thomthom

Да в основном; он может работать совместно с 'C++', 'C' и т. д., хотя. Моя путаница с вашим вопросом заключается в том, что вы пытаетесь использовать стандартную библиотеку или, в частности, «string.h» в своем проекте - или и то, и другое? –

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

В этом случае для как формы #include директива. В частности, хотя для реализаций обычно выполняется какой-то относительный поиск, чтобы найти файл, указанный с использованием синтаксиса include с двумя кавычками, C этого не требует. Это требует только того, если механизм реализации, используемый для разрешения двойных кавычек, терпит неудачу, компилятор должен отказаться от метода реализации, используемого для разрешения включений с угловыми скобками.

Кроме того, C указывает поведение только для случая, когда данное имя заголовка уникально определяет файл для включения. В зависимости от того, как один из них «однозначно», можно утверждать, что C не определяет какого-либо поведения вообще в описываемой вами ситуации, исходя из того, что вы не однозначно идентифицировали заголовок, который хотите включить. Это немного дико, однако - я думаю, что лучше интерпретировать «уникально» в свете определенного для реализации метода поиска заголовков.

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

#include "myapp/string.h"

Чтобы сделать это как можно более безопасным, убедитесь, что каталог src/ находится в пути поиска.

источник

2015-03-03 23:14:57

Мой файл 'string.h' вложен в подпапки:' ruby / api/string.h', и я включаю его как таковой: '#include 'ruby/api/string.h". Но '#include ' кажется, что разрешено в тот же файл. - Значит, вы говорите, что '#include ' может быть жестко закодирован для компилятора, который я использую с Xcode для первого просмотра в текущей папке - независимо? Есть ли способ переопределить это и заставить его сначала посмотреть в системные папки? – thomthom

@thomthom, что ваш заголовок находится во вложенном подкаталоге, уже никоим образом не меняет мой совет. Если результирующее имя может быть признано заголовком при компиляции источников, которые не предоставляют такой заголовок, то у вас есть конфликт имен, который лучше избегать. Вы все равно можете сделать это, нажав его в подкаталог, то есть 'myapp/ruby / api/string.h'. Если вы не хотите изменять имя, вам необходимо обратиться к документации для каждого компилятора, который вы используете, чтобы выяснить, как справиться с этой проблемой. –

Я немного запутался в этом «Вы все еще можете сделать это, нажав его в подкаталог», но я не вижу, как эта подпапка отличается от текущей подпапки, в которой она находится. Я нахожу это в документах CLang: «Директива #include, которая находит файл относительно текущего каталога, рассматривается как включающая системный заголовок, если включенный файл рассматривается как системный заголовок». хотя - я не вижу, как включающий файл обрабатывается как системный заголовок. Я догадываюсь, что мне в конечном итоге придется конфисковать и просто переименовать. Однако он надеялся найти окончательную причину. – thomthom

После просмотра your gist я заметил несоответствие с вашего экрана:

HEADER_SEARCH_PATHS = /Users/thomas/SourceTree/SUbD/SUbD/../ThirdParty/include/ruby/mac /Users/thomas/SourceTree/SUbD/SUbD/../ThirdParty/include/ruby/mac/universal-darwin12.5.0

Это должно быть:

HEADER_SEARCH_PATHS = /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include

источник

2015-03-03 23:36:20

Те, где от моей цели. Добавление '$ (inherit)' в список до того, как эти пути ничего не повлияли. Переименование моего 'ruby/api/string.h' на' ruby / api/string.hpp' действительно обошелся. Но все же это меня задевает, когда я не могу найти окончательного ответа. – thomthom

'HEADER_SEARCH_PATHS' не должен содержать ваших пользователей, включая пути, которые, как предполагается, должны содержать USER_HEADER_SEARCH_PATHS. –

Эти пути - это сторонние библиотеки. – thomthom

Почему Xcode 6 неправильно включает путь пользователя до пути к системе?

ответ

Смежные вопросы