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

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

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.

> > As a side note: any progress / plans for a release capable of hashed build
> directories?
> > 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.

-- 
Best regards,
Martin Dyring-Andersen