do we handle header paths (for addons) right on osx?

[ofZach]

[ofZach]

sorry for the empty issue :)

via weshoke/ofxOpenVDB#1 cc @sterlingcrispin

it seems like there are potentially two issues with header paths on xcode:

(a) we have always search user paths set to true, in this case, a header from the user path was being chosen over a header from a framework. setting it to false fixed this issue.

"Specifies whether the compiler searches for headers in the project directory before searching system directories. This build setting is used only with GCC 4.0 and later."

this doesn't seem like a good idea to me and can lead to gnarly / hard to compile issues.

(b) we are putting addon headers in HEADER_SEARCH_PATHS but there is also USER_HEADER_SEARCH_PATHS

https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW86

https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW21

it seems like one is for < > type headers and the other is for "" type headers.... It's not clear if we are using the right one.

[ofZach]

for sure I have seen issues similar to the one with ofxOpenVDB with conflicting header includes (ie, things that have the same name as system headers). I'm of the opinion that this flag should be set to no and not yes in the template:

I think it was inadertantly set to yes because it sounds really helpful "always look at user paths"

sure! go for it!

but really, it's kind of dangerous, because it really means "always look at user paths FIRST" and the sort of compile errors you get from choosing a user header over a system header can give you massive headaches, etc.

[arturoc]

i think that's probably just the default. if it's disabled won't we get the opposite problem? trying to include a use header that has the same name and relative path to a system one will include the system one instead?

If we've really changed this setting when creating the project then lets turn it off but if it's the default i'd leave it like it is i've also reported in the openvdb addon issue which would be the way to fix this without having to change this setting

[ofZach]

ah right I can see the opposite problem.... I will dig around some more but it seems like we've had this setting for a while now.

[ofZach]

for more info, here's the quick help entry on this setting, which explains it in more detail:

If enabled both #include <header.h>-style and #include "header.h"-style directives will search the paths in "User Header Search Paths" before "Header Search Paths", with the consequence that user headers (such as your own String.h header) would have precedence over system headers when using #include <header.h>. This is done using the -iquote flag for the paths provided in "User Header Search Paths". If disabled and your compiler fully supports separate user paths, user headers will only be accessible with #include "header.h"-style preprocessor directives.

For backwards compatibility reasons, this setting is enabled by default, but disabling it is strongly recommended. [ALWAYS_SEARCH_USER_PATHS]