Boost logo

Boost :

Subject: [boost] [build] File / path lengths difficult to manage on Windows
From: Ben Craig (ben.craig_at_[hidden])
Date: 2013-11-13 09:16:38

I was unzipping boost 1.55 on my Windows machine, into what I thought was
a reasonable location. 7-zip eventually complained about a file that it
could not write because the path was too long. Most APIs on Windows
restrict paths to ~260 characters. The longest file in the boost 1.55
release is the following:


This is 207 characters long. Next on the list are a whole bunch of html
and png documentation files, all with length 174. Here is one example:


As you may notice, the end of that particular file ends in a uuid / guid.
It may be as easy as making that uuid appear 30 or 40 characters sooner in
the path.

Is it unreasonable to ask that the boost zip only use half (130
characters) of the available Windows path size for itself?

On a related note, is it unreasonable to ask that an --abbreviate-paths
build of boost limit itself to 130 characters? I acknowledge that this
one is a bit harder to solve as there can be a large number of build
"pivots" that all add to the path, but some clients (like me) need to
layer other build pivot and version information on top of what boost
already provides, and I need some amount of character wiggle room to make
that happen.

This isn't currently in as bad of a shape as the zip file. For an
outdated piece of information, my win64 builds of boost 1.50 have a path
part of 151 characters.


Is there significant value in putting "bin.v2\libs" in the path?

Boost list run by bdawes at, gregod at, cpdaniel at, john at