|
Boost : |
Subject: Re: [boost] [build] File / path lengths difficult to manage on Windows
From: Charles_J_Wilson_at_[hidden]
Date: 2013-11-13 11:36:48
When building on windows, I've taken to building at the root of a volume.
Although at some point this methodology will also fail.
Charles Wilson
Principal Software Development Engineer
Dell | Enterprise Solutions Group
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Ben Craig
> Sent: Wednesday, November 13, 2013 6:17 AM
> To: boost_at_[hidden]
> Subject: [boost] [build] File / path lengths difficult to manage on Windows
>
> 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:
>
> boost_1_55_0\libs\geometry\doc\html\geometry\reference\spatial_indexe
> s\boost__geometry__index__rtree\rtree_parameters_type_const____ind
> exable_getter_const____value_equal_const____allocator_type_const___.
> html
>
> 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:
>
> boost_1_55_0\doc\html\images\accumulators\structboost_1_1accumulator
> s_1_1detail_1_1is__tail__variate__feature_3_01tag_1_1tail__variate_3_01b
> d5040caa5e48b0af425af2314206bf.png
>
> 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.
>
> boost\bin.v2\libs\test\build\msvc-11.0\rls\adrs-mdl-64\async-excpt-on\dbg-
> symbl-on\lnk-sttc\thrd-mlt\libboost_unit_test_framework-vc110-mt-
> 1_50.lib.rsp
>
> Is there significant value in putting "bin.v2\libs" in the path?
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk