2016-07-06 2 views
2

У меня есть зависимостей заголовков файлов C++, которые я указываю в моем скрипте waf с параметром includes=... на bld.program().waf не корректно обнаруживает зависимости C++ #include

Я знаю, что конфигурация сборки waf видит, что включает, потому что моя программа правильно компилируется.

Однако, когда я изменяю заголовочный файл, waf не обнаруживает изменения. То есть, когда я запускаю waf build после изменения содержимого включенного заголовка, ничего не перекомпилируется.

Разве waf не должен определять #include "..." зависимости автоматически?

Как устранить эту проблему?

Я просмотрел каталог build/c4che, чтобы узнать, могу ли я иметь в виду конфигурационные файлы, хранящиеся там. Упоминание «включить» в WAP-файлы .py файлов подозрительно отсутствует.

Я использую waf версию 1.9.0.

Я также пробовал это с помощью waf 1.8.19 и получил тот же результат.

EDIT: Я заменил свой оригинальный сложный 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']) 
+0

Не так много проблемы C++. С помощью прямых систем построения GNU make опция -M 'используется для создания файлов зависимостей заголовков, которые могут быть включены в Makefile. –

+2

Мое утверждение состоит в том, что это проблема с waf, а не с C++. Я не хочу создавать зависимости в Makefile с использованием -MM, поэтому я использую waf. – jsp

+0

Я еще не уверен, почему ваш пример не работает, я пытаюсь понять, могут ли документы пролить свет. https: // WAF.io/book/# _ include_processing – leetNightshade

ответ

2

Ваша проблема заключается в том, что вы используете включает в себя из каталога проекта. По умолчанию waf не использует внешние, включает в себя зависимости (например, систему), чтобы ускорить работу. Решения я знаю:

1/ Организуйте свой проект, чтобы ваш включать каталог под WAF верхней директории:

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

2/ Изменить верхний каталог. Я думаю, top = .. должен работать (не проверен).

3/ Телль WAF идти абсолютным путем добавления этой строки в начале build():

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

4/ зависимостей Использование GCC путем загрузки gccdeps WAF модуля.

Решение 1 /, вероятно, самое лучшее.

Кстати, я предпочитаю, чтобы моя директория сборки из исходного дерева. Используйте out = ../build в своем wscript, если вы хотите построить из исходного дерева.

my2c

+0

В главе 10.2.1 [waf book] (https://waf.io/book/#_include_processing) четко показан пример используемого заголовка, который не находится в том же каталоге, что и источник. Я думал, что это была цель параметра 'include' для' bld.program() '. В нем говорится: «Включение системы включает пути, которые должны быть определены во время конфигурации и добавлены к переменным INCLUDES». – jsp

+2

@jsp: да. Вы можете использовать include из вашего текущего исходного каталога. Я сказал, что waf не рассматривает файл за пределами его верхнего каталога, как проверенные зависимости по умолчанию. Обычно он предназначен для игнорирования системных зависимостей. В приведенном вами примере книги Waf каталог «..» - это верхний каталог, а не вне его. Я могу изменить свой ответ ради ясности. – neuro

+0

Я получаю это сейчас. Я ошибочно полагал, что waf будет отличать мои включения от системы, только в силу того, что он указан в параметре includes для bld.program(). Я переместил свой wscript на верхний уровень, как вы предложили в 1), и deps теперь работают так, как ожидалось. Спасибо за разъяснения. Я принял ваш ответ. – jsp

Смежные вопросы