Re: [Boost-build] test-suite / run problem with paths containing spaces

Subject: Re: [Boost-build] test-suite / run problem with paths containing spaces
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-06-24 09:51:57

Martin Dyring-Andersen wrote:

> Hi Vladimir,
> 
> Thank you for the quick reply!
> 
> I'm using bjam built from 1.39 sources, bjam --version outputs:
> Boost.Build V2 (Milestone 12)
> Boost.Jam 03.1.17
> 
>> Can you update Boost.Build from SVN and try again? I've just fixed this. If
>> you
>> were using some system version of Boost.Jam, you'd also need to build
>> Boost.Jam
>> 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
> export 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"
> export 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.

Doh! Can you update and try again? I've put quote in a wrong place.

>> 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?) 

Well, Boost CRC is probably not strong enough for this purpose :-)

> or, alternatively, use the Windows 
> Wide/Unicode filesystem functions to support the long paths.

Is there some alternative API that does not have path length limits?

> 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.

Well, we'd rather have hashed directory names as option everywhere, since long
paths are inconvenient on linux as well.

- Volodya