cmake include_directories在AFTER / BEFORE之后订购

问题描述

我在源码树中有一个名为time.h的文件，正如系统time.h。这不能改变。我遇到了cmake的问题，当我使用include_library选项时，它被转换为-I标志，这意味着即使对于<>包含，我的自定义time.h也优先于系统time.h。这是一个definiti no-no。

我尝试使用include_directories（AFTER dir1 dir2），但它仍然生成-I选项而不是预期的-idirafter。

解决方案

我不认为这是CMake的问题;无论在 #include 中是否使用引号或括号，并且不管

中的各种选项如何，gcc都会在系统之前找到您的time.h code> include_directories 。在

$ b $ include_directories 的c> AFTER 选项仅与gcc命令中列出的目录顺序相关，它与gcc的 -idirafter 标志。

这不是一个很好的计划，可以让自己的文件具有与系统文件相同的名称，但如果你的双手是绑在一起的，你可以避免这个问题，而不必重新命名time.h，通过更充分地限定你自己包含的路径，而不是例如

  CMakeLists.txt：include_directories（$ {PROJECT_SOURCE_DIR} / src）
 
头文件：#include< time.h> //我们希望但不要获得系统
 #includetime.h//我们想要获得自定义的
  

更类似于

  CMakeLists.txt：include_directories（$ {PROJECT_SOURCE_DIR}）
 
头文件：#include< time.h> //我们想要并获得系统
 #includesrc / time.h//我们想要并获得自定义的
  

另一种选择是坚持你当前的 #include 设置（使用系统的尖括号time.h和引用为你自己），而不是在CMakeLists.txt中使用 include_directories 。相反，我认为你可以用类似的东西替换它：

  set（CMAKE_C_FLAGS$ {CMAKE_C_FLAGS} -iquote $ {PROJECT_SOURCE_DIR} / src）
  

使用 -iquote 很可能因为由 -idirafter 指定的目录（在这种情况下不正确）被视为系统，所以它比 -idirafter 目录，因此有警告被压制等等。

如果你选择了这个选择，可能值得评论CMakeLists.txt来解释为什么没有 include_directories 以避免将来的重构恢复为使用更普通的 include_directories 命令。

$ b $总而言之，如果可能的话，最好的选择是重命名你的time.h文件。

I have a file in source tree which name is "time.h", exactly as system "time.h". This cannot be changed. I have encountered a problem with cmake that when I use include_library option it is translated to -I flag which means that my custom "time.h" takes prcedence over system time.h even for <> includes. This is a definiti no-no.

I tried using include_directories (AFTER dir1 dir2) but it still generate -I option instead of expected -idirafter.

解决方案

I don't think this is a problem with CMake; I believe gcc will always find your "time.h" before the system one, regardless of whether you use quotes or brackets in the #include and regardless of the various options in include_directories. See the entries for -I and -isystem in the gcc documentation

The AFTER option of CMake's include_directories relates only to the order of the directories as listed in the gcc command, it doesn't relate to gcc's -idirafter flag.

It's not a great plan to have your own files with identical names to system files, but if your hands are tied, you could avoid this issue without renaming time.h by qualifying the path for your own includes more fully, so rather than e.g.

CMakeLists.txt:  include_directories(${PROJECT_SOURCE_DIR}/src)

header file:     #include <time.h>  // we want but don't get system one
                 #include "time.h"  // we want and get own custom one

something more like

CMakeLists.txt:  include_directories(${PROJECT_SOURCE_DIR})

header file:     #include <time.h>      // we want and get system one
                 #include "src/time.h"  // we want and get own custom one

An alternative option would be to stick with your current #include setup (using angle brackets for the system time.h and quotes for your own) and not use include_directories at all in the CMakeLists.txt. Instead I think you could replace it with something like:

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -iquote ${PROJECT_SOURCE_DIR}/src")

Using -iquote is probably a better option than -idirafter since the directory specified by -idirafter is (in this case incorrectly) treated as a system directory, and as such has warnings suppressed, etc.

If you do go for this choice, it's probably worth commenting the CMakeLists.txt to explain why there is no include_directories to avoid future refactoring reverting back to use the more normal include_directories command.

All in all, your best option if at all possible would be to rename your "time.h" file though.

这篇关于cmake include_directories在AFTER / BEFORE之后订购的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！