Re: [boost] path length too long for 64 bits builds

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [boost] path length too long for 64 bits builds

Boost - Build mailing list
On 27.10.2017 9:24, Vicente J. Botet Escriba via Boost wrote:

> Hi,
>
>
> we have an issue since we have added threadapi= .
>
>
> On 64 bits windows machines we are seen
>
> Austin Beer said in
> https://github.com/boostorg/thread/pull/188#issuecomment-339829423
>
> "FYI, the 64-bit Windows builds are failing due the unit tests
> exceeding the 260 character filepath limit on Windows. Every filepath
> includes
> |\msvc-14.1\debug\address-model-64\threadapi-win32\threading-multi|.
> Do you know if there is an easy way to shorten this? On the 32-bit
> builds the filepaths don't have |\address-model-64| which is just
> enough to keep them under the 260 character limit so they don't fail."
>
>
> Is there a workaround to this issue without changing the specific part
> of the test files folder structure?
>
>
> Best,
>
> Vicente
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


Options --abbreviate-paths or --hash could be helpful:
http://www.boost.org/build/doc/html/bbv2/overview/invocation.html#bbv2.overview.invocation.options

HTH,

Gevorg

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: [boost] path length too long for 64 bits builds

Boost - Build mailing list
Vicente,
I have the same issue with VxWorks cross-compile on Windows, I use the  
b2 --abbreviate-paths
Which shortens the directory names enough that the tests complete.

Brian

> -----Original Message-----
> Gevorg Voskanyan via Boost-build
> Sent: Friday, October 27, 2017 3:10 AM
> To: [hidden email]; [hidden email]
> Cc: Gevorg Voskanyan
> Subject: Re: [Boost-build] [boost] path length too long for 64 bits builds
>
> On 27.10.2017 9:24, Vicente J. Botet Escriba via Boost wrote:
> > Hi,
> >
> >
> > we have an issue since we have added threadapi= .
> >
> >
> > On 64 bits windows machines we are seen
> >
> > Austin Beer said in
> > https://github.com/boostorg/thread/pull/188#issuecomment-339829423
> >
> > "FYI, the 64-bit Windows builds are failing due the unit tests
> > exceeding the 260 character filepath limit on Windows. Every filepath
> > includes
> > |\msvc-14.1\debug\address-model-64\threadapi-win32\threading-multi|.
> > Do you know if there is an easy way to shorten this? On the 32-bit
> > builds the filepaths don't have |\address-model-64| which is just
> > enough to keep them under the 260 character limit so they don't fail."
> >
> >
> > Is there a workaround to this issue without changing the specific part
> > of the test files folder structure?
> >
> >
> > Best,
> >
> > Vicente
> >
> >
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: [boost] path length too long for 64 bits builds

Boost - Build mailing list
Hi

This issue is a symptom of poor bjam scalability.
I think, some changes are needed to solve the scalability problem.
Otherwise, we will have endless workarounds.

The “threadapi” feature illustrates the  problem:

1. A feature added by some project leads to increasing the number of build
variants
for every project it uses as dependency. Path length increases too (unless
the actual feature value
is its default value and the feature is not symmetric). Eventually it
reaches the system limit.
However, the dependency projects can not have any knowledge about this new
feature,
so we have many identical build variants placed in different folders.
Every new feature with two possible values increases number of such
duplicates twice.
We have the time and the disk space wasted.

2. For "threadapi" feature to work correctly (in particular, with
cross-compilation)
we were forced to make it global (i. e. “builtin”). This is far not perfect.
If we use such a workaround, is there some reason to have non-builtin
features?

Alexander

-----Исходное сообщение-----
From: Kuhl, Brian via Boost-build
Sent: Friday, October 27, 2017 6:31 PM
To: Boost.Build developer's and user's list
Cc: Kuhl, Brian
Subject: Re: [Boost-build] [boost] path length too long for 64 bits builds

Vicente,
I have the same issue with VxWorks cross-compile on Windows, I use the
b2 --abbreviate-paths
Which shortens the directory names enough that the tests complete.

Brian

> -----Original Message-----
> Gevorg Voskanyan via Boost-build
> Sent: Friday, October 27, 2017 3:10 AM
> To: [hidden email]; [hidden email]
> Cc: Gevorg Voskanyan
> Subject: Re: [Boost-build] [boost] path length too long for 64 bits builds
>
> On 27.10.2017 9:24, Vicente J. Botet Escriba via Boost wrote:
> > Hi,
> >
> >
> > we have an issue since we have added threadapi= .
> >
> >
> > On 64 bits windows machines we are seen
> >
> > Austin Beer said in
> > https://github.com/boostorg/thread/pull/188#issuecomment-339829423
> >
> > "FYI, the 64-bit Windows builds are failing due the unit tests
> > exceeding the 260 character filepath limit on Windows. Every filepath
> > includes
> > |\msvc-14.1\debug\address-model-64\threadapi-win32\threading-multi|.
> > Do you know if there is an easy way to shorten this? On the 32-bit
> > builds the filepaths don't have |\address-model-64| which is just
> > enough to keep them under the 260 character limit so they don't fail."
> >
> >
> > Is there a workaround to this issue without changing the specific part
> > of the test files folder structure?
> >
> >
> > Best,
> >
> > Vicente
> >
> >
_______________________________________________
Unsubscribe & other changes:
https://lists.boost.org/mailman/listinfo.cgi/boost-build 

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: [boost] path length too long for 64 bits builds

Boost - Build mailing list
Le 27/10/2017 à 18:19, Alexander via Boost-build a écrit :

> Hi
>
> This issue is a symptom of poor bjam scalability.
> I think, some changes are needed to solve the scalability problem.
> Otherwise, we will have endless workarounds.
>
> The “threadapi” feature illustrates the  problem:
>
> 1. A feature added by some project leads to increasing the number of
> build variants
> for every project it uses as dependency. Path length increases too
> (unless the actual feature value
> is its default value and the feature is not symmetric). Eventually it
> reaches the system limit.
> However, the dependency projects can not have any knowledge about this
> new feature,
> so we have many identical build variants placed in different folders.
> Every new feature with two possible values increases number of such
> duplicates twice.
> We have the time and the disk space wasted.
>
> 2. For "threadapi" feature to work correctly (in particular, with
> cross-compilation)
> we were forced to make it global (i. e. “builtin”). This is far not
> perfect.
> If we use such a workaround, is there some reason to have non-builtin
> features?
>
> Alexander
Hi,

I'm really sorry to break users that uses Boost.Build in this way.
We needed to have cross compilation of Boost.Thread. This is the best
solution we found.
If you consider this is a showstopper for Boost 1.66, please tell us and
create a ticket.
If someone else has a better solution, please, proposes a PR as soon as
possible.

As this change concerns all the Boost.Build users, I would expect a
Warning on the Boost.Build release notes whith the workaround they can
apply.

Best,
Vicente

P.S. I like a lot the way Boost.Build organize the built files depending
on the different features. IIUC, there is always a valid workaround to
the patch size issue.
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build