Re: [boost] Windows Develop Tests Failing

Subject: Re: [boost] Windows Develop Tests Failing
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-03-13 18:01:52

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.