On Nov 20, 2006, at 10:32 PM, Andrew Cunningham wrote: I understand that the header search paths should be different for each target, so the target should find the correct header file (e.g. "Target1/A.h" and Target2/A.h) in my example. I definitely had done this. According to the search paths, Target 2 should not be finding Target1/A.h, but it is.
But what you seem to be saying is that I have caused the problem by adding the header file to the project, thus causing XCode to do something in the one of its builds phases that makes the header file available to all targets, thus defeating the header search paths above. It's really handy to have on-click access to header files, and seems a pretty typical way of organizing things that most people do , in say, shudder, Visual Studio. So instead of removing the header file can I just make sure the header file(s) is not a member of any target?
One thing that Xcode does do, though, is to pass "headermaps" to the compiler to speed up file system searching. This is known to have problems in targets that use two different headers with the same name in the same target though we don't know of cases where this breaks with different targets. Setting the custom build setting USE_HEADERMAP = NO in both targets, then rebuilding, would show whether this is indeed the problem.
In either case, it's worth filing a bug with the detailed (-v) build transcripts of both targets so we can see why the wrong one is getting picked up, and make it work more intuitively.
Chris |