On Friday 13 March 2015 16:17:05 Tom Kent wrote:
All my windows test runners for develop (teeks99-08*) have been failing for the last few days (I just noticed).
They run for a long while, then end with the following at the end of their results/bjam.log file: common.mkdir D:\local\teeks99-08\d\results\boost\bin.v2\libs\multiprecision\test\number_c oncept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\archi tecture-x86\debug-symbols-off\link-static\runtime-link-static
if not exist "D:\local\teeks99-08\d\results\boost\bin.v2\libs\multiprecision\test\number_ concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\arch itecture-x86\debug-symbols-off\link-static\runtime-link-static\\" mkdir "D:\local\teeks99-08\d\results\boost\bin.v2\libs\multiprecision\test\number_ concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\arch itecture-x86\debug-symbols-off\link-static\runtime-link-static"
failed to write output file 'D:\local\teeks99-08\d\results\boost\bin.v2\libs\multiprecision\test\number_ concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\arch itecture-x86\debug-symbols-off\link-static\runtime-link-static\number_concep t_check_cpp_dec_float_no_et.obj.rsp'!
At first I thought I might be running out of disk space or something, but that all seems fine. Has anyone seen this before?
This may be caused by excessively long paths. I believe, recent changes to the build system added address-model-64\architecture-x86 which were not typically present before. Which makes me wonder. (a) When will MS get around to fix this in Windows? (I suspect "never" is the answer). (b) AFAIK, there is Windows API that can work with long paths (32767 chars or something?). Can bjam be updated to use these API to work around the problem?