My code rely on a library that has an issue: one of the .h file is missing an include which used to work and now fails with the latest version of Xcode.
Unfortunately this library includes this file using the “quote include” syntax:
// from foo.cpp (which is in the library itself)
#include "foo.h" // this is the one that has an error
I cannot change the code of the library (I cannot change neither foo.cpp or foo.h). I want to provide an alternative version of foo.h and have the compiler use it instead.
Unfortunately using target_include_directories does not work because the file is included with "foo.h" not <foo.h>.
Is there another way to override the behavior of the compiler so that "foo.h" gets looked up somewhere else?
Why should #include "foo.h" be a problem over #include <foo.h>? The only difference between the two should typically be that #include "foo.h" will look in the same directory as the current file first, then search everywhere that #include <foo.h> would if not found there. And target_include_directories() works fine for both cases, so I suspect there’s a different problem than the one you think may be happening.
with #include <foo.h> the compiler looks in the in the list of directories specified by target_include_directories() in the order specified. So you can override where foo.h is being picked up from, by having another folder first in the list.
with #include "foo.h", the compiler first looks in the same folder and only if not found, then looks in the list of directories specified by target_include_directories() in the order specified. In other words, the list of directories specified by target_include_directories() is meaningless if the ".h" is present in the same folder it is included from… And as a result, because of this “rule”, there does not seem to be a way to override where foo.h is being picked up from.
My question was whether there was a way to override the second behavior (“looking first in the same folder”) that I am unaware of.
If the foo library is buggy, get a new version of it. Or downgrade your Xcode to a supported version by that library. Or make a new version of the whole library.
Injecting headers into 3rd party libraries is doomed to fail in the long-term. Consider someone upgrades the library in several years, and are confused of the error messages; Until they find out, that there is an old modified copy of the header used.
CMake can’t do anything here, as it’s the compiler’s behavior to do so. Most compilers won’t have options to influence the behavior.