[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: Duane Campbell
Subject: RE: Any known problems with relative paths in VPATH on Windows?
Date: Tue, 7 May 2013 09:51:24 -0700

Erik, are you familiar with subst command?

If not, you might find it handy as a work-around for windows limitations:
   subst someUnusedDriveLetter: c:\very-long-src-dir
   subst S: c:\very-long-src-dir
Then use S:\ in-place of c:\very-long-src-dir\ throughout your makefile.

FYI: subst operation is implemented low-level in windows, and it quite 
efficient - near zero i/o overhead
   (whereas similar function done via "net use" has substantial i/o overhead)


-----Original Message-----
From: Eli Zaretskii [mailto:address@hidden 
Sent: 2013-05-07 Tuesday 09:37
To: Erik Carstensen
Cc: Duane Campbell; address@hidden
Subject: Re: Any known problems with relative paths in VPATH on Windows?

> 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
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

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)


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.

reply via email to

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