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 like 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) .duanec. -----Original Message----- From: Eli Zaretskii [mailto:[email protected]] Sent: 2013-05-07 Tuesday 09:37 To: Erik Carstensen Cc: Duane Campbell; [email protected] Subject: Re: Any known problems with relative paths in VPATH on Windows? > Date: Mon, 6 May 2013 21:55:11 +0200 > From: Erik Carstensen <[email protected]> > Cc: Duane Campbell <[email protected]>, [email protected] > > On Mon, May 6, 2013 at 9:48 PM, Eli Zaretskii <[email protected]> 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 [email protected] https://lists.gnu.org/mailman/listinfo/make-w32
