Re: [boost] Windows Develop Tests Failing

Subject: Re: [boost] Windows Develop Tests Failing
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-13 20:26:36

On 14 Mar 2015 at 0:29, Andrey Semashev wrote:

> > 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?

Yes. bjam can't cope with the long paths typically generated by 
Jenkins. Java programs don't have the 260 char limit on Windows, 
hence Jenkins has no problem with them.

> 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).

Stephan told me that the cost benefit analysis is currently "it's not 
worth the benefits given the investment needed". Given that OS X has 
not once but twice extended PATH_MAX now, I do find this surprising 
given the resources Microsoft has to hand. Agreed, it's hardly the 
most interesting of refactors, but it sure would make much pain for 
everyone else go away.

> (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?

Proposed Boost.AFIO has always used the NT kernel API directly, and 
therefore paths are case sensitive like POSIX, nearly follow POSIX 
semantics, and have a 32,767 char limit which is substantially better 
than any other POSIX implementation. I believe AFIO currently exceeds 
Mingw and Cygwin in how conforming its POSIX semantics are.

See 
http://boostgsoc13.github.io/boost.afio/doc/html/afio/reference/classe
s/path/normalise_path.html.

AFIO also has the big advantage of being somewhat debugged. You would 
be quite surprised at just how many surprises and quirks there are in 
correctly talking to filing systems e.g. deleting a directory tree 
which will randomly fail on Windows if you do it too quickly :). You 
can examine the AFIO source code to get some idea.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/