Subject: Re: [Boost-build] [boost] path length too long for 64 bits builds
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-10-29 07:19:58
Le 27/10/2017 Ã 18:19, Alexander via Boost-build a Ã©critÂ :
> 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
> we were forced to make it global (i. e. âbuiltinâ). This is far not
> If we use such a workaround, is there some reason to have non-builtin
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
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
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk