Re: [Boost-users] [bjam] Generated path approaches 255 character OS limit

Subject: Re: [Boost-users] [bjam] Generated path approaches 255 character OS limit
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-11-06 14:31:38

Mat Marcus wrote:

> On Thu, Nov 6, 2008 at 9:54 AM, Vladimir Prus <vladimir_at_[hidden]> wrote:
>> Steven Watanabe wrote:
>>
>>> AMDG
>>>
>>> Peter Klotz wrote:
>>>> When compiling Boost 1.37.0 using this bjam command line under Windows I obtained the error
>>>> message below:
>>>>
>>>> bjam -q -sNO_COMPRESSION=1 --build-type=complete --without-graph --without-math --without-mpi
>>>> --without-python --without-serialization --without-signals --without-wave --toolset=msvc-8.0
>>>> architecture=x86 address-model=64
>>>>
>>>> failed to write output file
>>>> 'bin.v2\libs\test\build\msvc-8.0\debug\address-model-64\architecture-x86\asynch-exceptions-on\link-static\runtime-link-static\threading-multi\libboost_prg_exec_monitor-vc80-mt-sgd-1_37.lib.rsp'!
>>>>
>>>> Obviously the path I started from (70 characters) combined with the bjam generated path (192
>>>> characters) exceeds the OS limit of 255 characters per filename.
>>>>
>>>> Does the bjam generated path really have to be this long? Can I shorten it somehow?
>>>>
>>>
>>> You can pass --abbreviate-paths to bjam
>>
>> Probably I should just go ahead and implement MD5 paths.
>>
>> - Volodya
> 
> Is there a way to get boost build to generate the same paths when
> using either an msvc-compiled bjam or a cygwin compiled-bjam? Right
> now, if I understand correctly, if I invoke bjam with:
> 
>     some_path/bin.cygwinx86/bjam.exe threadapi=posix target-os=cygwin gcc
> 
> target-os-cygwin doesn't show up in the generated path. But if I invoke:
> 
>     some_path/bin.ntx86/bjam.exe threadapi=posix target-os=cygwin gcc
> 
> the generated path will include
> 
>   .../target-os-cygwin/threadapi-pthread/...
> 
> I would like to force the same path (or hash) to be used. As far as I
> know, this is not possible today. It would be nice if hashes were
> implemented to contain all features used in the build, since the 255
> character ceiling should no longer be a problem. Then it would be
> possible to share the directory used for built artifacts, regardless
> of how the build tool was compiled.

With hashing, the paths will be the same. The target-os feature is
defaulted to the host-os bjam was built on -- with cygwin considered
a OS. When build paths are constructed, the properties which values
are equal to default values and hidden from the path. This behaviour
optimizes for the case where you're building on one OS for the same
OS.

If hashing is used, then there's no need to suppress default values,
since it does not make paths anyway longer, so the property set
will be exactly the same. Oh, wait, no :-( I think the <host-os>
property will be different.

I am not really sure what is the right solution for your problem.
If we always include target-os in the target path, this will make
the common usage less nice. It's probably possible to declare that
cygwin is actually windows, but I don't know if cygwin users will
be happy.

- Volodya