[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Any known problems with relative paths in VPATH on Windows?

From: Erik Carstensen
Subject: Re: Any known problems with relative paths in VPATH on Windows?
Date: Mon, 6 May 2013 20:51:21 +0200

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.


long=$(call q,01234567890123456789)

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

default: $(files)
        @echo ok

On Mon, May 6, 2013 at 6:22 PM, Eli Zaretskii <address@hidden> wrote:
> Date: Mon, 6 May 2013 15:45:43 +0200
> From: Erik Carstensen <address@hidden>
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]