WAF: конфликт между MinGW (GCC) и MSVC 2012

Question

Я только что натолкнулся на WAF. Я использую MinGW-w64 исключительно для сборки вещей. Но недавно я установил MSVC 2012, потому что иногда требуется создавать различные небольшие утилиты, которые имеют некоторые проблемы при сборке с MinGW.

WAF рекомендует не кодировать выбор компилятора в wscript, а лучше выберите его из командной строки, что звучит очень разумно, и я придерживаюсь этой философии в этом случае. Итак wscript должен выглядеть так (забудьте о boost):

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


def configure(ctx):
    ctx.load(('compiler_cxx', 'boost'))
    ctx.check_boost()

Затем просто введите в командной строке:

waf --boost-includes=D:/Applications/Boost/include --check-cxx-compiler=gxx configure build

--check-cxx-compiler=gxx заставляет WAF искать MinGW в первую очередь, поскольку по умолчанию в Windows WAF предпочитает MSVC в первую очередь.

ПРИМЕЧАНИЕ: MinGW-w64 находится в PATHMSVC нет, но WAF все еще может найти его из-за реестра, я думаю.

Итак, WAF выдает это в выводе конфигурации (что означает, что все круто):

Checking for 'gxx' (c++ compiler)        : D:\Applications\MinGW-w64\bin\g++.exe

Затем он начинает строить, и я получаю этот длинный спам:

Build failed
Traceback (most recent call last):
  File "D:\Applications\WAF\waf-1.7.8-77e2cdd38ea2930f982e3aabf335fdb7\waflib\Task.py", line 123, in process
    ret=self.run()
  File "D:\Applications\WAF\waf-1.7.8-77e2cdd38ea2930f982e3aabf335fdb7\waflib\Task.py", line 47, in run
    return m1(self)
  File "D:\Applications\WAF\waf-1.7.8-77e2cdd38ea2930f982e3aabf335fdb7\waflib\Task.py", line 47, in run
    return m1(self)
  File "<string>", line 28, in f
  File "D:\Applications\WAF\waf-1.7.8-77e2cdd38ea2930f982e3aabf335fdb7\waflib\Tools\msvc.py", line 685, in exec_command_msvc
    return self.exec_command_nomsvc(*k,**kw)

    ... (repeated thousands of times)

  File "D:\Applications\WAF\waf-1.7.8-77e2cdd38ea2930f982e3aabf335fdb7\waflib\Tools\msvc.py", line 685, in exec_command_msvc
    return self.exec_command_nomsvc(*k,**kw)
File "D:\Applications\WAF\waf-1.7.8-77e2cdd38ea2930f982e3aabf335fdb7\waflib\Tools\msvc.py", line 684, in exec_command_msvc
    if self.env['CC_NAME']!='msvc':
  File "D:\Applications\WAF\waf-1.7.8-77e2cdd38ea2930f982e3aabf335fdb7\waflib\ConfigSet.py", line 35, in __getitem__
    self=self.parent
RuntimeError: maximum recursion depth exceeded

Как MSVC должен участвовать в этом процессе сборки?! - Я понятия не имею. Но в любом случае, здесь идет самая интересная часть. Давайте нарушим рекомендации и жесткий код GCC, чтобы быть нашим выбором в wscript:

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


def configure(ctx):
    ctx.load(('gxx', 'boost'))
    ctx.check_boost()

Затем мы вызываем:

waf --boost-includes=D:/Applications/Boost/include configure build

И посмотрите в выходных данных конфигурации:

Checking for program g++,c++             : D:\Applications\MinGW-w64\bin\g++.exe
Checking for program ar                  : D:\Applications\MinGW-w64\bin\ar.exe

ПРИМЕЧАНИЕ. Заметили, как изменился выход? Это уже загадка для меня, потому что cxx_compiler Инструмент (используемый в предыдущем случае) сам вызывает ctx.load('gxx') за кулисами. Так как же эти 2 выхода могут отличаться в этих 2 случаях?

Затем WAF начинает строить, и вы идете:

'build' finished successfully (1.155s)

Круто верно?:) Дайте мне знать, что вы, ребята, думаете, и, надеюсь, кто-то уже сталкивался с этим.

В главных ролях

WAF 1.7.8

MinGW-w64 (GCC 4.7.2)

MSVC 2012

Answer 1

Я отправил сообщение об ошибке Томасу Надю, и он узнал, что это произошло из-за одного из последних патчей. Отмена этого патча устранила проблему. Посмотрите эти 2 проблемы для более подробной информации:

• Выпуск 1243
• Выпуск 1237