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