On 9/4/2010 5:15 PM, Timothy Madden wrote:
On 04.09.2010 11:55, Vladimir Prus wrote:
Timothy Madden wrote:
[...]
>>> >>> Maybe cl.exe somehow feels it is invoked from a subprocess of >>> VS, or >>> sees some environment variables, and knows how to output the >>> message ? >> >> Yes, it's watching for VS_UNICODE_OUTPUT environment variable. >> http://connect.microsoft.com/MSDNProductFeedbackCenterRedirect.aspx?pfcId=FD... >> > > Excelent ! > > I was still getting this problem with boost 1.44, so thank you > for this > information. Could boost better documented this somewhere ? > > Better yet, could the regex build process start by unsetting this > variable ? Should I report this somewhere ?
Do you always get those messages, or only when building a fresh tree for the first time?
The project pre-build event that I set up unpacks and compiles a boost release archive, that I place on source control as part of the project files, so I always compile a fresh tree.
Ah, this explains. Can you arrange for<boost-root>/bin.v2 directory to be created before you try to build boost. 1.44 has a bug whereby config log is written to<boost-root>/bin.v2/config.log, but the directory is not created.
I tried to interrupt the build process and start it again. The bin.v2 directory was there, but still no use ...
Ok -- and what if you set VS_UNICODE_OUTPUT environment variable before running the build? This would have to happen in your custom build step.
if I unset the variable, like set VS_UNICODE_OUTPUT=& .\bjam toolset=msvc-9.0 then nothings gets compiled. bjam just exists immediately and Visual Studio continues project compilation.
I found that devenv.com, invoked from the command line with a simple solution file and with VS_UNICODE_OUTPUT unset, instead of cl.exe, can properly capture the output from cl, and can properly be redirected.
Could the build process invoke devenv.com instead of cl.exe when testing for ICU for msvc-9.0 toolset ? And for msvc-10.0 I guess ... ?
Thank you, Timothy Madden
Phieewww ! I solved my problem: the damn nmake.exe must attempt some parsing on the commands it invokes, as it will run nothing following the & character on the command line. so set VS_UNICODE_OUTPUT=& .\bjam toolset=msvc-9.0 will not work in a makefile, but cmd /C "set VS_UNICODE_OUTPUT=& .\bjam toolset=msvc-9.0" will work as expected. The Microsoft nmake reference in MSDN does not mention & as a special character, though ... Timothy Madden