> so it's not just parentheses.
> I wonder if it has to do with archive support.
Ah, interesting.
> This should be reported on Savannah.
Perhaps the OP would like the honor?
>> bla bla bla
> This is perfectly legitimate
(Indeed. I only mentioned it to demonstrate that open parenthesis didn
On Thu, 2006-11-30 at 18:30 -0800, Martin Dorey wrote:
> -rw-rw-r-- 1 martind software 0 2006-11-30 16:44 bracket()
> [EMAIL PROTECTED]:~/tmp/make-2006-11-30$ make 'bracket()'.t
> make: *** No rule to make target `bracket().t'. Stop.
That seems to be a bug. I can reproduce it. On the other han
> You didn't specify what errors you got when you had the parens in
there
Here you go:
[EMAIL PROTECTED]:~/tmp/make-2006-11-30$ ls -l bracket*
-rw-rw-r-- 1 martind software 0 2006-11-30 16:44 bracket(
-rw-rw-r-- 1 martind software 0 2006-11-30 16:44 bracket()
[EMAIL PROTECTED]:~/tmp/make-2006-11
On Thu, 2006-11-30 at 16:52 -0800, Martin Dorey wrote:
> Works for me if I remove the two close-parentheses and replace the white
> space with underscores. Open-parenthesis fine, close-parenthesis bad.
> Weird. Close-parenthesis is also bad with Debian sarge's make-3.80.
I suspect that has to d
> I'd be interested to see the same test with "odd characters" but not
> whitespace.
Works for me if I remove the two close-parentheses and replace the white
space with underscores. Open-parenthesis fine, close-parenthesis bad.
Weird. Close-parenthesis is also bad with Debian sarge's make-3.80.
Martin Dorey wrote:
However, your point about programs invoked by make inheriting the
setrlimit() is definitely something that seems problematic. Perhaps
GNU
make could change the stack limit back to what it was after it forks
but
before it execs its child. I wonder what hap
On Thu, 2006-11-30 at 22:51 +, Jon Grant wrote:
> Martin Dorey elucidated on 30/11/06 21:32:
> > Isn't this more relevant? (Quoting from here on.)
>
> Yeah, Looking at it again I can see that's likely the problem.
I might need to reopen that bug; there definitely was a change in
behavior WRT
Martin Dorey elucidated on 30/11/06 21:32:
> Isn't this more relevant? (Quoting from here on.)
Yeah, Looking at it again I can see that's likely the problem.
Jon
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-mak
> However, your point about programs invoked by make inheriting the
> setrlimit() is definitely something that seems problematic. Perhaps
GNU
> make could change the stack limit back to what it was after it forks
but
> before it execs its child. I wonder what happens if you change a
limit to
Isn't this more relevant? (Quoting from here on.)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul D. Smith
Sent: Saturday, November 25, 2006 14:09
To: Paul D. Smith; [EMAIL PROTECTED]; bug-make@gnu.org
Subject: [bug #18369] pattern rules don't work with spaces in filenames
U
Hi
Dan Jacobson elucidated on 30/11/06 17:14:
> $ cat Makefile
> .PRECIOUS:.%.time
> %.t:.%.time;
> .%.time:%
> bla bla bla
> $ ls -1
> Makefile
> 霧峰-桐林(有經朝陽科技大學) - Wufeng-Tonglin (Via Zhaoyang Technical University)
>
> Well, no amount of quoting will enable me to
> $ make '霧峰-桐林(有經朝陽科技大學)
$ cat Makefile
.PRECIOUS:.%.time
%.t:.%.time;
.%.time:%
bla bla bla
$ ls -1
Makefile
霧峰-桐林(有經朝陽科技大學) - Wufeng-Tonglin (Via Zhaoyang Technical University)
Well, no amount of quoting will enable me to
$ make '霧峰-桐林(有經朝陽科技大學) - Wufeng-Tonglin (Via Zhaoyang Technical University)'.t
make: *** N
Follow-up Comment #2, bug #12209 (project make):
-- code snippet from function.c:1475++
/* make sure that CreateProcess() has Path it needs */
sync_Path_environment();
if (!process_begin(hProcess, command_argv, envp, command_argv[0], NULL)) {
/* register process for wait */
The syn
13 matches
Mail list logo
