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依賴關係

回答

相關問題