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