From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2002-05-15 09:16:40
David Abrahams wrote:
> ----- Original Message -----
> From: "Markus Schöpflin" <markus.schoepflin_at_[hidden]>
> You can work around your problem by using -sALL_LOCATE_TARGET=... to build
> > > to a top-level directory (map a drive letter if neccessary)
> > Unfortunaltely not. ".\bjam -sALL_LOCATE_TARGET=c:\" still gives
> > an error.
> The same error?
Yes, but one or two directories further down.
> > > In Boost.Build v2 we can try to work around this problem by making the
> > > mkdir rule CD to the parent directory, if neccessary.
> > Won't help. I tried repeatedly to "mkdir 0123456789 && cd 0123456789"
> > and it still fails when reaching a limit somewhere near 256 chars.
> Where would the 256 characters be? the point is that each directory being
> created would be reached through a sequence of "cd" commands to reach an
> appropriate depth.
> Or are you saying that absolute paths cannot be longer than 256 characters,
> no matter how they are formed?
Exactly. Try it for yourself. Just repeat the mkdir && cd command sequence
and you will encounter an error sooner or later.
> > Looks like we have to use the native WIN32 API to solve this. I could
> > offer to venture a look at the jam sources if this is feasible.
> I don't see how that would help, but maybe you do. So feel free to look at
If have the hope that the native WIN32 API doesn't have this limit when
used with a file system that supports longer path names. I have the
feeling I'm hitting a limit within cmd.exe. So instead of calling mkdir
maybe using CreateDir() from the API would help.
I just found something in the CreateDir() documentation:
There is a default string size limit for paths of 248 characters.
This limit is related to how the CreateDirectory function parses paths.
Windows NT/2000/XP: To extend this limit to nearly 32,000 wide
characters, call the Unicode version of the function and prepend
"\\?\" to the path. For more information, see File Name Conventions.
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