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

Mat Marcus wrote:

On Thu, Nov 6, 2008 at 9:54 AM, Vladimir Prus 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