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 10:44:31

Hi Vladimir,

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

Thanks a lot - now tests run perfectly on all platforms!

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

Just trying to keep it simple. :-)

I googled a bit for CRC collision rates. This page seems interesting and concludes that chances of a CRC64 collision is extremely low (at least for that class of input data):
http://apollo.backplane.com/matt/crc64.html


So maybe it is not such a bad idea after all. 

As for a free md5 implementation, IANAL, but this puppy seems to fit licensing wise:
http://sourceforge.net/project/showfiles.php?group_id=42360


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

There is a limit, but it is high enough that it should be sufficient: 32,767 characters according to http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx

I couldn't find a definitive answer for all *nixes, but the limit seems to be around 4096 characters.

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

It would be great to support both options, since I guess that long paths will continue to cause problems with used in shell scripts etc.

Thanks again for your help on the original issue. :-)

-- 
Best regards,
Martin Dyring-Andersen