Subject: Re: [Boost-build] test-suite / run problem with paths containing spaces
From: Martin Dyring-Andersen (mda_at_[hidden])
Date: 2009-06-24 07:44:51
Thank you for the quick reply!
I'm using bjam built from 1.39 sources, bjam --version outputs:
Boost.Build V2 (Milestone 12)
> Can you update Boost.Build from SVN and try again? I've just fixed this. If
> were using some system version of Boost.Jam, you'd also need to build
> from SVN. If you were using 1.39 version of Boost.Jam, it's good enough.
Here is an update when latest Boost.Build from SVN:
1) Windows still works
2) Debian still gives warning (but runs test successfully):
/bin/sh: line 1: MyProject: command not found
/bin/sh: line 2: export: `LD_LIBRARY_PATH': not a valid identifier
3) FreeBSD now works without warning
4) Darwin continues to fail. This is dumped (rewritten for clarity):
DYLD_LIBRARY_PATH="$HOME/Projects/TFS/MyProject Name Containing Spaces/trunk/stage/somedynamiclib/darwin-4.0.1/release/address-model-32/architecture-x86/threading-multi:$DYLD_LIBRARY_PATH
It looks to me like something is wrong with the quoting. If my understanding is correct (I'm a Windows guy :-), it should look like this:
DYLD_LIBRARY_PATH="'$HOME/Projects/TFS/MyProject Name Containing Spaces/trunk/stage/somedynamiclib/darwin-4.0.1/release/address-model-32/architecture-x86/threading-multi':$DYLD_LIBRARY_PATH"
.. though I must admit that I am a bit confused about how the end quote turned up after export DYLD_LIBRARY_PATH" in the original dump.
> > As a side note: any progress / plans for a release capable of hashed build
> > I have run into the path length issue on Windows a number of times, for now
> I have
> > avoided them by using --abbreviate-paths but it feels like postponing the
> inevitable. ;-)
> There are no concrete plans at present. If you, or somebody else, find me a suitably licensed SH1 or MD5 implementation, it would be a big help :-)
Actually I was going to suggest either using the Boost CRC library (since I don't think it is actually necessary with a crypto-safe hash anyway?) or, alternatively, use the Windows Wide/Unicode filesystem functions to support the long paths.
As I understand it, this is mainly an issue on Windows - so it maybe it would be better to preserve the existing behaviour on all platforms and simply fix the Windows path limit issue. I would be happy to help with this if you can point me in the right direction.
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