[英]Library tries to include <string.h> but includes “string.h” from my project, how to prevent?
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). 我的项目中有一个
string.h
使用-I
将其添加到我的标题搜索路径中(因为我使用的是CMake并从项目根目录而不是string.h
所在的目录进行编译)。
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). 该项目使用一个外部库,该库尝试在我包含的其中一个头文件中
#include <string.h>
(标准C头),并且意外地最终包含了我的string.h
(因为它位于头搜索路径中) <>
包含在内)。
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>
. 在
SDL_stdinc.h
的第60行,有#include <string.h>
。
How can I get around this? 我该如何解决?
2 rules I use: 我使用的2条规则:
1) Include files that I have created are always included via a relative-path, and never included in an environment PATH. 1)我创建的包含文件始终通过相对路径包含,而从未包含在环境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. 2)我仅通过环境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". 作为从事MLOC大小工作的承包商(几百个承包商),我发现了将符号添加到简单文件的原因,我们将其称为“ 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. 我使用他们的工具找到“ Foo.hh”,对其进行了修改,然后编辑了我正在使用的文件,以使用放置在此处的新符号。
During rebuild, however, the compiler complained the symbol was unknown. 但是,在重建期间,编译器抱怨该符号未知。
So I double checked both files, and realized there must be another "Foo.hh". 因此,我仔细检查了两个文件,并意识到必须有另一个“ 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?). 然后,我启动了整个系统的构建,并带有使编译器在编译输出中报告每个编译单元包括的所有文件的选项(我认为-H?)。
At first I only visited the compilation unit I was interested in, and found the second "Foo.hh". 最初,我只访问了我感兴趣的编译单元,并找到了第二个“ Foo.hh”。
Curiosity got the best of me, so I grepped thru the compilation log, and found thousands of includes of "Foo.hh". 好奇心得到了我的最好的帮助,所以我翻阅了编译日志,发现了成千上万的“ 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". 原来有5条路径到达“ Foo.hh”。 Comparing them, the 5 files were of 3 different versions.
比较它们,这5个文件具有3个不同的版本。
(FYI - I removed my symbol from the 1st, added the new symbol to the 2nd, and (by direction) ignored the other 3 files.) (仅供参考-我从第一个符号中删除了我的符号,在第二个符号中添加了新符号,并且(按方向)忽略了其他三个文件。)
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.