Windows has limits on path length, approximately (as I don't remember exactly 
off-hand):
  256 chars total in dir or file path
  128 chars in each element in dir or file path

.duanec.


From: make-w32-bounces+dcampbell=nvidia....@gnu.org 
[mailto:make-w32-bounces+dcampbell=nvidia....@gnu.org] On Behalf Of Erik 
Carstensen
Sent: 2013-05-06 Monday 11:51
To: Eli Zaretskii
Cc: make-w32@gnu.org
Subject: Re: Any known problems with relative paths in VPATH on Windows?

Here is a makefile that reproduces it. The makefile is a bit hacky (creates a 
directory and calls itself from it); this is just to be able to reproduce it in 
a single makefile. The 'else' clause is the relevant one. If you put the 
makefile in a reasonable path (I used c:\cygwin\tmp), it will find a, b and c, 
but not the long filename.

SHELL=cmd.exe

q=$(1)$(1)$(1)$(1)$(1)
long=$(call q,01234567890123456789)

ifeq ($(findstring $(long),$(shell cd)),)
default:
        -mkdir $(long)
        $(MAKE) -C $(long) -f ..\Makefile
else
src=..\src\$(long)
$(info $(shell mkdir ..\src) $(shell mkdir $(src)))
files=a b c 0123456789012345678901234567890123456789
$(info $(foreach f,$(files),$(shell echo > $(src)/$(f))))
VPATH=$(src)

default: $(files)
        @echo ok
endif

On Mon, May 6, 2013 at 6:22 PM, Eli Zaretskii 
<e...@gnu.org<mailto:e...@gnu.org>> wrote:
> Date: Mon, 6 May 2013 15:45:43 +0200
> From: Erik Carstensen <mandolae...@gmail.com<mailto:mandolae...@gmail.com>>
>
> I found the problem, there seems to be a limit in VPATH resolution of
> around 256 characters, where ..\ entries in the path are not collapsed. In
> my example, I ran make from c:\path\very-long-build-dir, and had
> ..\very-long-src-dir on VPATH; very-long-src-dir and very-long-build-dir
> were a bit over 200 characters together, so some but not all files in the
> src dir exceeded the length limit and were not found.
>
> I don't know where this limit comes from; if it's a Windows limitation,
> there's not much we can do. In my example it would have helped to collapse
> the ..\:s in VPATH before resolving files, but it would just move the
> problem a few characters. I have solved it myself in my use case, by
> printing a warning when detecting dangerously long paths. I'm not sure if
> it would make sense for make itself to automatically warn on too long paths.
I doubt that it has anything to do with Windows.

I'll look into this, but it would help if you could show a simple
example that can be used to reproduce this problem.

Thanks.

_______________________________________________
Make-w32 mailing list
Make-w32@gnu.org
https://lists.gnu.org/mailman/listinfo/make-w32

Reply via email to