waf没有正确地检测到C++ #include依赖关系

我有我在waf脚本中用bld.program（）的includes=...参数指定的C++头文件依赖关系。waf没有正确地检测到C++ #include依赖关系

我知道waf构建配置看到包含，因为我的程序编译正确。

但是，当我更改头文件时，waf没有检测到更改。也就是说，当我在更改包含的头文件的内容后运行waf build时，什么也得不到重新编译。

是不是应该自动确定#include“...”的依赖关系？

如何解决此问题？

我查看了build/c4che目录，看看能否理解存储在那里的配置文件。在waf生成的.py文件中提到“include”是可疑的。

我正在使用waf版本1.9.0。

我也试过这个waf 1.8.19，并得到了相同的结果。

编辑：我用下面列出的更简单的一个替换了原来的复杂wscript，而且我仍然得到相同的行为。

这里是我的WScript：

top = '.' 
out = 'build' 
CXXFLAGS = ['-fopenmp', '-Wall', '-Werror', '-std=c++11', '-Wl,--no-as-needed'] 

def options(ctx): 
    ctx.load('compiler_cxx') 

def configure(ctx): 
    ctx.load('compiler_cxx') 
    ctx.env.CXXFLAGS = CXXFLAGS 

def build(ctx): 
    ctx.program(source="test_config_parser.cpp", target="test_config_parser", includes=["../include"], lib=['pthread', 'gomp'])

来源

2016-07-06 jsp

显然不是一个C++问题。使用直接的GNU make构建系统时，'-M '选项用于生成头文件相关性文件，这些文件可以被Makefile包含。 –

我的断言是这是waf的问题，而不是C++。我不想使用-MM在Makefile中生成依赖项，这就是为什么我使用waf的原因。 – jsp

我还不确定你的例子为什么不起作用，我试图看看这些文档是否可以解决问题。 https：//开头WAF。io/book /＃_ include_processing – leetNightshade

你的问题是，你使用包含了该项目的目录。默认情况下，waf不使用外部包含作为依赖关系（如系统包含）来加快速度。解我所知道的：

1/ 组织项目有你的包括WAF顶级目录下的目录：

top_dir/ 
    wscript 
    include/ 
     myinclude.h 
    sources/ 
     mysource.cpp

2/ 更改顶级目录。我认为top = ..应该工作（未测试）。通过加载gccdeps应用防火墙模块

waflib.Tools.c_preproc.go_absolute=True 
waflib.Tools.c_preproc.standard_includes=[]

4/ 使用gcc的依赖关系：

3/ 泰尔WAF去绝对通过在build()开始加入这一行。

解决方案1 /可能是最好的。

顺便说一句，我更喜欢让我的build目录不在源代码树中。如果您想构建出源树，请在wscript中使用out = ../build。

my2c

来源

2016-07-07 10:46:14 neuro

[waf book]（https://waf.io/book/#_include_processing）的10.2.1章节清楚地显示了一个与源不在同一个目录中的头文件的例子。我认为'bild.program（）'的'includes'参数的目的是。它说：“系统包含路径应在配置期间定义并添加到INCLUDES变量中”。 – jsp

@jsp：是的。您可以在当前的源目录中使用包含。我所说的是，waf在默认情况下不会将其顶层目录之外的文件视为已检查的依赖项。它通常旨在忽略包含依赖关系的系统。在引用的waf书籍示例中，“..”目录是最上面的目录，不在其外面。为了清楚起见，我编辑了我的答案。 – neuro

我现在明白了。我错误地认为waf会通过包含参数中指定的bld.program（）来区分我的包含和系统。我已经把你的wscript移到了顶层，正如你在1）中所建议的那样，现在deps可以按预期工作。感谢您的澄清。我已经接受你的答案。 – jsp

waf没有正确地检测到C++ #include依赖关系

回答

相关问题