On 31.07.2012, at 12:00, Rick Mann wrote: On Jul 31, 2012, at 1:02 , Andreas Grosam < email@hidden> wrote:
On 30.07.2012, at 22:25, Rick Mann wrote:
Unfortunately, that doesn't work when the headers you're using are generated by a tool that doesn't do the same thing.
Xcode itself is such a tool. For instance when building a static library public headers will be copied to a default location for which a header search path for a client is already set per "magic" by Xcode. Note that the public headers of the library do not appear as file references in the navigator in the main project. Any other tool possibly can copy headers anywhere you want. IF you have no control where a tool copies generated files, you can add a Copy Files Build Phase yourself, and let it copy anywhere you want utilizing Xcode's build settings variables. That will work always, and it will work with manually set header search paths - and possibly with Xcode's "magic" header search paths, too.
And by independent, I mean that if I change the file hierarchy in the project, I have to remember to change the header search paths.
Well, of course! You may have to change the import directive - but this is mostly effortless with search&replace. You may also set/change header search paths, though more rarely. A change in the file structure of your source files justifies this effort and usually only affects a few import directives.
Whether or not to search a particular folder (or group) in the Xcode file hierarchy should be a property of that folder. That way, if I move it, or rename it, or whatever, search paths go with it.
If you think Xcode adds a header search path for a *group* (yellow folder) in the navigator, this cannot work (and it never will)! It might work with a *folder reference* (the blue folder). But this would only be some kind of "convenience UI feature" - you can accomplish the same by adding a search path to the build setting.
On the other hand, if you already have file references to your headers in any group in the navigator - then this is where header maps can be good for (if you can cope with a flat header file namespace): you can locate headers from any source in that target with unqualified import directives.
But because the current search path setting is buried down inside the build settings (and could be on the project, or the target), it's MUCH harder to make sure it's kept consistent.
You probably like the magic header map feature, too much ;)
But there is no such danger of inconsistency. If you specify a header search path explicitly, it will be searched before any header map. You'll just be *explicit* - and avoid any possible conflicts which might be introduced with header maps. Also note, that almost all settings have a correspondence in the build settings panel (if not all) - and most of them have a direct correspondence to compiler and linker options.
What we have right now is at least two ways to set search paths. One is by adding a folder as a group,
I don't think so. Rather: adding a *file reference* for a header file to the navigator - which affects the header map. the other is by modifying the build settings.
yep.
Rather, for clarity, readability and for other reasons already mentioned, I would suggest to sparingly use explicit header search paths - and also *qualified* import directives.
Andreas |