On Saturday 14 March 2015 00:29:56 you wrote:
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\ar chi 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\numbe r_ concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\a rch itecture-x86\debug-symbols-off\link-static\runtime-link-static\\" mkdir "D:\local\teeks99-08\d\results\boost\bin.v2\libs\multiprecision\test\numb er_ concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\a rch 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\numbe r_ concept_check_cpp_dec_float_no_et.test\msvc-11.0\debug\address-model-64\a rch itecture-x86\debug-symbols-off\link-static\runtime-link-static\number_con cep 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?
(c) As an alternative, bjam could have an option to compress the path to a shorter hash value.