alloy/cocoapods — Issue #42: Discussion log from IRC regarding Xcode and header indexing.
Author: alloy
Created: 2011-11-03 10:36:36+00:00
State: open

```
10:31 kommen: alloy: got to talk to 2 xcode guys
10:32 kommen: we eventually got the headers thing to work
10:34 kommen: so the things we did:
10:35 kommen: * set the headers in the pods xcode project to be "public"
10:35 kommen: * use the header search path, not the user search path
10:36 kommen: * then use #include instead of "bla.h"
10:38 kommen: * override the ALWAYS_SEARCH_USER_PATHS to be YES on the target level
10:38 kommen: for some reason xcode doesn't inherit it from the xcconfig down to the targets for us
10:40 alloy: Hmm, I wonder if Xcode just checks the xcodeproj for headers with the ‘public’ attr or in the header search paths, because we do set the public attr
10:41 kommen: oh.
10:41 kommen: hmm, but they weren't public
10:41 alloy checking an actual project to see if it actually works ;)
10:45 alloy: Hmm, I forgot, where in Xcode 4 did you set the role again?
10:46 alloy: This is where we set the attr when generating the project btw: https://github.com/alloy/cocoapods/blob/master/lib/cocoapods/xcode/project.rb#L79
10:46 alloy: But maybe the fact that we don’t actually use the ‘headers build phase’ but a general ‘copy files build phase’ might have to do something with that?
10:49 alloy: I think the second and fourth are mutually exclusive. I.e. Not using the user search paths but still setting searching it to YES _seems_ as if it won't matter much.
10:49 alloy: Also, I wonder what the exact diff is between the regular search paths and the user’s search paths.
10:50 alloy: Finally, regarding ‘#include instead of "bla.h"’, is it important to use ‘include’ vs ‘import’? Or just the angle brackets vs the quotes?
10:50 kommen: don't know the difference. but the guys suggested it we should use the regular header search path, cause this is intended for libraries
10:51 kommen: well, it seems like a convention to use " for your own things, and <> for 3rd party stuff
10:51 alloy: Yeah indeed, I have been using it that way myself, but I was wondering more if the include vs import mattered too
10:52 alloy: Ok I see, well then we should probably change it to use the regular header search paths indeed.
10:54 alloy: Man, it’s too bad that we still don't have a full grasp on what xcode does…
10:55 kommen: the suggested that we let a user include a pod header in his files like , though that's a matter of taste
10:55 kommen: the = they
10:55 kommen: (man, my spelling is shit today)
10:56 kommen needs moar coffeez
10:59 alloy: Just checked a project and what is weird is that the ALWAYS_SEARCH_USER_PATHS setting is explicitly set to NO in the global project configuration, but on the app target it is not set and inherits YES.
11:00 kommen: yeah, something is off with the this one
11:01 alloy: Ugh, I know the feeling… More coffee ftw, up till a certain point ;)
11:03 alloy: With regards ot the extra namespacing, was there a technical reason for it, or just as extra indication to the reader where the header is located?
11:03 alloy: *to
11:03 kommen: I just feel really embarrassed... i didn't even know there's a #include *and* and #import :/
11:04 alloy: Hehehe. A day not having learned stuff is a day wasted!
11:04 kommen: as far as i understood, there's no technical reason, just more clarity where stuff comes from
11:05 kommen: (thats why they do #import instead of only Foundation.h)
11:05 alloy: Fair enough, so if that doesn't work yet then we can add that search path.
11:06 alloy: Right, but my idea (or actually jweinberg’s) was that we do that grouped by pod only. I.e.
11:07 alloy: But it doesn't hurt to add the root to search path too I guess
11:07 alloy: So people can choose which way they want to use it.
11:16 kommen: yeah, true
11:18 alloy: So where in Xcode 4 did you mark the headers as public?
11:18 alloy: Or is it just a matter of adding them to the right section of the ‘copy headers’ build phase?
11:22 kommen: alloy: honestly, i can't find the public setting right now either...
11:25 alloy: I know there used to be a place where you could set a checkbox, but I can’t find that, nor do suggestions from the web work (select headers, right click => change role).
11:25 alloy: So knowing now what Xcode actually does in the project data, I’m guessing that adding a header to the ‘public’ section of the ‘copy headers’ build phase sets the attribute.
11:26 alloy: But we don’t use that build phase at all atm, because of a bug during archiving, so we just copy them all with a normal copy files phase.
```