Library tries to include <string.h> but includes "string.h" from my project, how to prevent?

2.5k views Asked by At

I have a string.h in my project added it to my header search path with -I (because I'm using CMake and compiling from the project root directory rather than the directory where string.h is located).

The project uses an external library that tries to #include <string.h> (the standard C header) in one of its header files that I include, and accidentally ends up including my string.h (because it was on the header search path that inclusion with <> uses).

Here's the (edited) error message that reveals this:

In file included from /path/to/project/src/random_source_file.cpp:3:
In file included from /usr/local/include/SDL2/SDL.h:67:
In file included from /usr/local/include/SDL2/SDL_main.h:25:
In file included from /usr/local/include/SDL2/SDL_stdinc.h:60:
In file included from /path/to/project/src/string.h:7:
etc.

At line 60 in SDL_stdinc.h there's the #include <string.h>.

How can I get around this?

1

There are 1 answers

2
2785528 On BEST ANSWER

2 rules I use:

1) Include files that I have created are always included via a relative-path, and never included in an environment PATH.

#ifndef DTB_SUPPORT_HH
#include "../../bag/src/dtb_support.hh"
#endif

2) I only include Library files thru an environment PATH, and never using a relative path.

#include <string>

edit - origins:

My use of relative-path include grew out of the following experience:

As a contractor (one of several hundred) on a MLOC size effort, I found cause to add a symbol to a simple file, lets call it "Foo.hh".

I used their tool to find "Foo.hh", modified it, and edited the file I was working on to use the new symbol I put there.

During rebuild, however, the compiler complained the symbol was unknown.

So I double checked both files, and realized there must be another "Foo.hh".

I then lauched a build of the entire system, with option that caused the compiler to report in the compilation output all the files that were included for each compilation unit (I think -H?).

At first I only visited the compilation unit I was interested in, and found the second "Foo.hh".

Curiosity got the best of me, so I grepped thru the compilation log, and found thousands of includes of "Foo.hh". I had to gather these lines together, and sort them with the full path.

It turns out there were 5 paths to a "Foo.hh". Comparing them, the 5 files were of 3 different versions.

(FYI - I removed my symbol from the 1st, added the new symbol to the 2nd, and (by direction) ignored the other 3 files.)