Why does Xcode 6 incorrectly include from user path before system path?

Question

I'm trying to build a project I have done for Windows, Visual Studio under OSX using Xcode 6.1.1.

I'm running into an issue where in a file that needs to include #include <string.h>. However, in the same folder as the file that does this there is also a file that is named string.h.

Under my Visual Studio project this still resolves file, the system paths are searched first.

In the Xcode project I have made sure to set up my own paths under "User Header Search Paths" - Xcode expand to the correct path. I also set "Always Search User Paths" to No - which according to the docs says that the system paths should be searched first: 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

But yet the #include <string.h> seem to be treated as #include "string.h" for some reason.

The config is defined in the project and I've made sure the targets doesn't override this.

Is this some Xcode/OSX thing where system includes <> search the path of the including file first?

My local string.h file is located at ruby/api/string.h relative to the include path in my User Header Search Path.

---

Results of https://gist.github.com/thomthom/034b539bede38dd68261: https://gist.github.com/thomthom/034b539bede38dd68261

Answer 1

Have same issue with file <assert.h> in Xcode 13.4.

I fixed by set "No" for build setting "Search Paths" > "Use Header Maps".

Maybe help someone.

Answer 2

Upon viewing your gist I noticed a discrepancy from your screenshot:

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

This should be:

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

Answer 3

The paths searched to satisfy an #include directive and the order in which they are searched are implementation defined. That includes whether any user-specified include paths (if even supported) are searched before, after, or instead of any default paths.

That's the case for both forms of #include directive. In particular, although it is common for implementations to perform some kind of relative search to find a file specified using the double-quoted include syntax, C does not require that. It requires only that if the implementation-defined mechanism used for resolving double-quoted includes fails, the compiler must fall back on the implementation-defined method used for resolving angle-bracketed includes.

Moreover, C specifies behavior only for the case that the given header name uniquely identifies a file to include. Depending on how one construes "uniquely", one might claim that C does not define any behavior at all in the situation you describe, on the basis that you have not uniquely identified the header you want to include. That's a bit wild, though -- I think it's better to interpret "uniquely" in light of the implementation-defined method for locating headers.

Your best bet is to avoid header names that collide with standard header names. One version of that would be to put them in a subdirectory that will lend its name as a prefix. For example, put string.h in src/myapp/, and include it as

#include "myapp/string.h"

To make that as safe as possible, ensure that directory src/ is in the include search path.