Angled brackets vs "" in includes

[redorav]

Hi,

First of all, thanks for this great library! I'm trying to compile gainput on OSX and I'm hitting an error about headers not being correctly found:

"'gainput/gainput.h' file not found with include; use "quotes" instead"

It seems like you use angled brackets in gainput which Xcode treats as system headers. There's an option called Always Search User Paths (deprecated) that fixes the issue but ideally I wouldn't need to rely on this behavior as it's also marked as deprecated so will disappear in the future.

Thanks!

[RicoP]

You mean you have something like

#include <gainput/gainput.h> ?

That is normal C preprocessor syntax, you have to add the include folder to your include search list.

[redorav]

Sorry if I wasn't clear, what I mean is <gainput/gainput.h> should become "gainput/gainput.h" as the angled brackets are meant for "system" headers (whatever that means is up to the compiler/IDE) and quotes are meant for user headers.

Xcode complains about not being able to find the headers in its own system folders. As I mentioned there is a deprecated option to re-enable it, but I think it's risky in case deprecated means removed not too long from now.

[RicoP]

angled brackets are not only used for system headers, but also for external libs. that is very common practice.

[redorav]

Yes but I'm not talking about my cpp files using angled brackets to include gainput as #include <gainput/gainput>, but rather gainput's source files referencing their own headers with angled brackets. Basically I'm trying to build gainput as a library, and Xcode just refuses to build it. Perhaps there is a setting (other than the deprecated one) to be able to make it work?

[RicoP]

add "gainput/lib/include/" to your search path in xcode https://stackoverflow.com/a/14153027

[redorav]

Hmm, adding -I adds it to the system search path as far as I can tell from the link? Perhaps I'm wrong, but I think they are already in the search path, but in the user search path. I'm using premake to generate the projects and use includedirs to add the includes. They also have a sysincludedirs so I suppose I could also add them there. But I'm not convinced it's entirely correct. I'll try this at home regardless.

[RicoP]

That is what I do with premake. I never compiled my project on MacOS yet.

project "gainput"
  warnings "Off"
  includedirs { "../external/gainput/lib/include" }
  files { "../external/gainput/lib/source/**.h", "../external/gainput/lib/source/**.cpp" }

-- main projects
project "bez"
  files { "bez/**.h", "bez/**.cpp" }
  includedirs { "../external/gainput/lib/include" }
  links { "gainput" }

What is your issue? Does it work or not?

[redorav]

Yeah that's what I mean, I do that exact same thing as you do in premake and Xcode complains about the angled brackets and doesn't compile. It works fine on Windows but not on MacOS

[RicoP]

Ok, hard to say. I havent compiled on XCode so far, but in my mind this should work. I don't beliefe it's because of the brackets, literally every C++ library does it that way.

Maybe it's a premake issue?

[redorav]

I will do a few experiments tonight and let you know of the results. I know Xcode can be very picky about certain things. It may certainly be a premake issue like you say. I have been looking at other libraries and they do use angled brackets, so I'm not sure what the actual issue is right now.

[redorav]

Ok so I made a quick test with premake using includedirs and sysincludedirs. Using sysincludedirs gainput compiles just fine. If I look at the project properties:

· includedirs adds header paths to User Header Search Paths · sysincludedirs adds header paths to Header Search Paths

I searched for the difference between these two and I found this:

https://stackoverflow.com/questions/3429031/header-search-paths-vs-user-header-search-paths-in-xcode/3429301

In essence, Xcode will treat <> as system headers and "" as user headers. I'm not quite sure the difference is super clear though... certainly Visual Studio doesn't care too much and puts them all in the same place. It's certainly easy enough to use sysincludedirs in the premake script and be consistent with its usage. So, the TLDR is there's no bug, but one needs to be careful to put system and user includes as appropriate via premake. Thanks for the discussion and feedback :)