On Sat, May 4, 2013 at 9:23 AM, Eli Zaretskii wrote:
> > From: Duane Campbell
> > CC: "make-w32@gnu.org" , Duane Campbell
> >
> > Date: Fri, 3 May 2013 16:21:23 -0700
> >
> > I think gnu-make users need to be responsible for quoting (and proper
> slashes) for the cmd.exe shell.
>
> I coul
On Tue, May 7, 2013 at 6:51 PM, Duane Campbell wrote:
> 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
On Tue, May 7, 2013 at 6:36 PM, Eli Zaretskii wrote:
> The easiest way around the problem is this:
>
> VPATH = $(abspath ..\very-long-build-dir);$(abspath ..\yet-another-one)
>
>
I cannot do that, because very-long-src-dir contains spaces.
What I have done instead is to detect this condition
On Fri, May 3, 2013 at 9:20 PM, Eli Zaretskii wrote:
> You should use a backslash to produce a literal quote that should be
> passed to a program. That's what the Microsoft startup code provides
> as the way to get quote characters into programs.
>
Thanks! I thought I had tried that and faile
On Mon, May 6, 2013 at 9:48 PM, Eli Zaretskii 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'.
On the symp
hell 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 wrote:
> > Date: Mon, 6 May 2013 15:45:43 +0200
> &
On Mon, May 6, 2013 at 10:41 AM, Erik Carstensen
wrote:
> Hi,
>
> Are there any known problems or caveats with having relative paths with
> ..\ in VPATH on Windows?
>
I found the problem, there seems to be a limit in VPATH resolution of
around 256 characters, where ..\ entries
Hi,
Are there any known problems or caveats with having relative paths with ..\
in VPATH on Windows?
I'm getting some strange errors: I have a directory on the form
..\..\..\..\foo\bar on VPATH, where there are two .c files. make finds one,
but not the other, via VPATH, and make -d gives me no cl
On Fri, May 3, 2013 at 9:10 PM, Eli Zaretskii wrote:
> You are welcome to send patches. But just based on the above example,
> I don't yet see any compelling reason to change anything in the
> current development sources,
I just thought it might be a more lightweight and robust solution for th
When passing to a shell, it is evaluated to a single word " " if
cmd.exe evaluates it, but to an unquoted single space if make
short-circuits the cmd.exe argument.
Test case:
foo.mk contains:
SHELL=cmd.exe
$(info x is $(x))
default:
mkdir $(x)
Makefile contains:
SHELL=cmd.exe
defau
This makefile reproduces the problem:
SHELL=cmd.exe
default:
./x.bat ""
./x.bat
The first line succeeds on make 3.82, while the second line fails. With
master, both lines fail (because the first one is short-circuited as well)
It seems that the problem happens only when it is a path to a
On Thu, May 2, 2013 at 6:50 PM, Eli Zaretskii wrote:
>
> Make on Windows cannot support escaping with backslash when the shell
> is cmd.exe. And Make in general doesn't support file names with
> whitespace too well, you need to introduce blanks via variables, for
> it to work reliably. The only
On Thu, May 2, 2013 at 7:14 PM, Eli Zaretskii wrote:
> The first invocation of x.bat works, while the second one won't (''a' is
>
> not recognized as...)
>
> It's not a bug: cmd.exe doesn't know about '..' quoting, so this
> command is not supposed to work. That it does without redirection is
>
On Wed, May 1, 2013 at 5:39 PM, Eli Zaretskii wrote:
I fixed that in the repository; the patch is below if you want to try
> it.
>
So I assume then that make is expected to use the same quoting rules as CMD
when short-circuiting the shell. Then there is another bug: make's arg
quoting has some s
On Wed, May 1, 2013 at 5:39 PM, Eli Zaretskii wrote:
So now commands that use quotes go through the fast path, instead of
> being submitted to cmd.exe via a batch file, which exposed these
> commands to this (very old) bug.
>
> I fixed that in the repository; the patch is below if you want to try
On Mon, Apr 29, 2013 at 4:40 AM, Eli Zaretskii wrote:
>
> Alas, this won't help you for long, because the next release of Make
> will not invoke cmd.exe just because the command line has quotes.
> Such commands are also short-circuited in the development sources.
>
Oh. This seems to change make
When building master, I'm getting compiler and linker errors for _S_ISDIR
not being defined. This patch seems to fix the problem:
--- a/dir.c
+++ b/dir.c
@@ -1212,7 +1212,7 @@ local_stat (const char *path, struct stat *buf)
strncpy (parent, path, plen - 2);
parent[plen - 2] = '\0';
On Sun, Apr 28, 2013 at 7:26 PM, Eli Zaretskii wrote:
> Thanks for the report. (Any real reason to use batch files whose
> names include whitespace?)
>
Yes. I'm working on a make-based system for building add-on modules to a
certain program. The build system is distributed as a Windows install
Hi,
I have the following makefile:
SHELL=cmd.exe
default:
"a b.bat" xy
"a b.bat" "x y"
a\ b.bat xy
a\ b.bat x\ y
I also have a file 'a b.bat', which contains a single line:
echo a b
Now when I run make, this happens:
/tmp$ /cygdrive/c/mingw64-i686-20110207/bin/m
19 matches
Mail list logo
