I've just run into misery with WAF. I use MinGW-w64 exclusively to build stuff. But, recently, I've installed MSVC 2012 because sometimes it is required to build various small utilities which have some issues when building with MinGW.
WAF encourages not to hard-code the compiler choice into wscript, but rather select it from the command line which sounds very reasonable and I'm with that philosophy in this case. So the wscript should look like this (forget about boost):
def options(ctx):
ctx.load(('compiler_cxx', 'boost'))
def configure(ctx):
ctx.load(('compiler_cxx', 'boost'))
ctx.check_boost()
Then one simply types in the command line:
waf --boost-includes=D:/Applications/Boost/include --check-cxx-compiler=gxx configure build
The --check-cxx-compiler=gxx forces WAF to look for MinGW in the first place since by default on Windows WAF prefers MSVC first.
NOTE: MinGW-w64 is in the PATH, MSVC is not, but WAF can still find it due to registry I guess.
So, then WAF gives this in the configuration output (which means everything is cool):
Checking for 'gxx' (c++ compiler) : D:\Applications\MinGW-w64\bin\g++.exe
Then it starts building, and what I get is this long spam:
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
How should MSVC be involved in this build process?! - I have no idea. But anyway, here comes the most interesting part. Lets break recommendations and hard-code GCC to be our choice in the wscript:
def options(ctx):
ctx.load(('boost'))
def configure(ctx):
ctx.load(('gxx', 'boost'))
ctx.check_boost()
Then we invoke:
waf --boost-includes=D:/Applications/Boost/include configure build
And see in the configuration output:
Checking for program g++,c++ : D:\Applications\MinGW-w64\bin\g++.exe
Checking for program ar : D:\Applications\MinGW-w64\bin\ar.exe
NOTE: Noticed how the output has changed? This is already a mystery to me because the cxx_compiler tool (used in the previous case) itself calls ctx.load('gxx') behind the scenes. So how could these 2 outputs be different in these 2 cases?
Then WAF starts building and there you go:
'build' finished successfully (1.155s)
Cool right? :) Let me know what you guys think, and hopefully someone has already encountered this.
Starring
WAF 1.7.8
MinGW-w64 (GCC 4.7.2)
MSVC 2012
