On Dec 4, 2006, at 7:18 PM, Jim Wintermyre wrote: At 2:12 AM -0800 11/21/06, Chris Espinosa wrote: Target membership has nothing to do with where #include files are found. In most cases, you don't even want your #include files to be target members, lest they get acted on (compiled, copied into the Headers directory, copied into the Resources directory, etc.) during a build.
In CodeWarrior, if you recall, headers were not even project members, much less target members. The main reason they're usually target members in Xcode is that the SCM support is integrated at the project level, so to have your headers under SCM control they need to be in the project.
I may be totally out to lunch here, but I thought having headers in targets also had something to do with symbol indexing. I seem to remember that in the past, if I didn't have certain headers actually in the target, then if I Cmd-double-clicked a type that was declared in one of those headers, it wouldn't be found. But that could be ancient history...
True, but yes, ancient (pre-Xcode, I believe).
Also, when I recently converted a bunch of CW projects to XCode, the importer imported all the header files that were actually referenced by the CW project, even though the headers weren't explicitly in the CW project. Is SCM support the only reason this is being done?
Yes, primarily to take advantage of SCM. Before we did that people complained that they would change their headers, commit their projects in Xcode -- and the sources would go in the repository without matching headers, screwing up their cow orkers.
Chris |