Header/User Header Search Paths

Question

Created Oct ’17

Replies 4

Boosts 0

Views 8.7k

Participants 3

I am having some difficulty steering the preprocessor/compiler to find the intended versions of .h files in a project. The primary build of the project uses a set of targets and schemes, and has user header files along with the rest of its .m files in one folder. My version of the build has variants of the targets and schemes, plus variants of the original .h and .m files in a different folder. I have set up the User Header Search Paths to search my folder for .h files first, then search the primary folder. My intent is to use the modified .h files in my folder for my builds instead of the originals in the primary folder.

What appears to happen is that if the build gets a .m from the primary folder, the build process will search the primary folder first for .h files imported by that .m.

What in Xcode can change how the user header search path is used?

Is this a consequence of using precompiled headers? I notice there's a Build Option "Precompiled Header Uses Files From Build Directory" I hadn't noticed before, I wonder if this is somehow affecting how the search path is used.

Thanks,

Mike

Boost

Answer 1

crenelle OP

Oct ’17

Another specific example of my problem is that a .m file from the variants folder is including a .h file that only exists in the originals folder; that .h file in turn includes a .h file that exists in both the originals and the variants folders. The user headers search path indicates that the build process should get the second .h file from the variants folder, but it instead gets it from the originals.

The only effective fix I've been able to use so far is to change the name of the .h files in the originals folder that have modified versions with the same name in the variants folder so that the build process can't find them when it looks for them in the wrong place.

0

Answer 2

QuinceyMorris OP

Oct ’17

Part of the problem here is that the C language has some rules (AFAIK, I'm not an expert in this area) that control the order in which include filenames are searched for. I believe Xcode itself also has some heuristics that try to be clever about finding header files, beyond the "include paths" setting. (For example, it might cache where it found the header files the first time, which might work against your supplying replacements in a different place.)

I would suggest one of these approaches:

1. If you don't need unmodified .m files to pick up modified .h files due to search order, then I would be inclined to give all your new/modified .h files unique names and include them by unique name in your code.

2. Otherwise, I would be inclined to move all the original .h files into a separate "headers" folder from the original .m files. That might better ensure that your replacements (in a different "headers" folder) are found more strictly in accordance with the path order in the settings.

0

Answer 3

crenelle OP

Oct ’17

Thanks for replying!
I don't have a lot of control over the original .h and .m files, so I've created my new build targets and schemes on top of the existing project, leaving everything in the original project as untouched as possible since the original project is actively in development. I re-integrate my stuff with the original code after every release of the original.

I'd rather have Apple fix the Xcode user header search path mechanism (if it is not quite right as it is) than work around it 🙂

The jury is still out on whether Xcode's user header search path is working as expected or not.

My workaround has been to add an underscore to the tail end of the name (not the suffix) of the original .h files that I don't want to use, buut search paths were created to avoid having to do this.

0

Answer 4

KMT OP

Oct ’17

>What in Xcode can change how

Sorry if I missed it - which version Xcode?

0