> Date: Mon, 6 May 2013 21:55:11 +0200 > From: Erik Carstensen <mandolae...@gmail.com> > Cc: Duane Campbell <dcampb...@nvidia.com>, make-w32@gnu.org > > On Mon, May 6, 2013 at 9:48 PM, Eli Zaretskii <e...@gnu.org> wrote: > > > > Maybe c:\very-long-src-dir\..\very-long-build-dir together exceeded > > 260 characters? > > > No, make can find 'c:\very-long-src-dir\..\very-long-build-dir\a', but not > 'c:\very-long-src-dir\..\very-long-build-dir\very-long-filename'.
I looked into this. It's Windows after all, not Make. Once 'c:\very-long-src-dir\..\very-long-build-dir\very-long-filename' becomes longer than 260 characters, every file-related library function I tried fails, even though normalizing the file name would give something well within the 260-char limits. The functions that fail and cause Make think the file is not anywhere along VPATH are 'stat' and/or 'opendir', and also '_fullpath' that is called in between. I guess some file-name normalization routine called by these has a bug, like too small buffer or maybe an explicit test for the length of the string applied before the normalization is attempted. > On the symptoms, it seems that the problem in my case would be solved by > normalizing (collapsing ..) earlier, but I'm not sure it's feasible to do > so (and it just gives us a few more characters to play with). The easiest way around the problem is this: VPATH = $(abspath ..\very-long-build-dir);$(abspath ..\yet-another-one) etc. Given that too many library functions fail with such names, I find it impractical to work around this problem inside Make, because the fix would have to be in too many places, while the workaround in the Makefile, as shown above, is very simple. _______________________________________________ Make-w32 mailing list Make-w32@gnu.org https://lists.gnu.org/mailman/listinfo/make-w32