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

[Eli Zaretskii]

> Date: Mon, 6 May 2013 21:55:11 +0200
> From: Erik Carstensen <address@hidden>
> Cc: Duane Campbell <address@hidden>, address@hidden
> 
> On Mon, May 6, 2013 at 9:48 PM, Eli Zaretskii <address@hidden> 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.