[bug #15720] Expansion of variables inside export fails on Win32

2006-02-13 Thread Agent Zhang
Follow-up Comment #3, bug #15720 (project make): Indeed you're correct. My Win32 build of GNU make 3.81beta4 detects my Cygwin sh.exe automatically and makes use of it without a warning. Mixing Cygwin sh.exe with non-Cygwin app such as win32-make.exe can be problematic. So I wrote a simple

[bug #15718] Weird behavior of the SHELL variable on Win32

2006-02-13 Thread Agent Zhang
Follow-up Comment #4, bug #15718 (project make): Hi, Paul~ Everything you said is very true. I'm a Perl programmer and I know what `perl foo' and `perl -e foo' do. And I know GNU make always sends `-c' to the shell as well. Furthermore, I also quite agree the idea of SHELLFLAGS and the current

[bug #15937] default_names test dies on Cygwin; $port_type = 'UNIX'; should be 'W32'

2006-03-03 Thread Agent Zhang
Follow-up Comment #1, bug #15937 (project make): default_names attempts to avoid testing with only makefile and Makefile present on case-insensitive file systems (DOS/WIN32 platforms) by using the test: if ($port_type eq 'UNIX') Unfortunately, Cygwin was set to 'UNIX' (the default

[bug #15718] Weird behavior of the SHELL variable on Win32

2006-03-04 Thread Agent Zhang
Follow-up Comment #12, bug #15718 (project make): P.S. In general, I think that setting SHELL to anything but a shell, either cmd.exe or some version of Unixy shell, is playing with fire If I'm not misunderstanding you, the Win32 build of GNU make 3.81rc is supposed to work with cmd.exe,

[bug #15719] Make jobserver feature not supported on WINDOWS32 platforms

2006-03-04 Thread Agent Zhang
Follow-up Comment #5, bug #15719 (project make): greg~ In my first mail to Paul, I also mentioned the Cygwin erratic failures in features/parallelism. However, at that time I was using GNU make 3.80. With GNU make 3.81beta4, it seems to me it's harder to reproduce the random failures since

[bug #15718] Weird behavior of the SHELL variable on Win32

2006-03-04 Thread Agent Zhang
Follow-up Comment #15, bug #15718 (project make): Hmm...here is the screen-shot: D:\Agent2002\AISystem1.0\SVK\de\UniSimu\Methodologywin32-make SHELL=cmd test dmd -quiet binary_tree_set3.d Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp.

[bug #15947] tests/features/escape - 'path=p\:' test fails on Cygwin - cannot stat illegal filename

2006-03-06 Thread Agent Zhang
Follow-up Comment #2, bug #15947 (project make): On Cygwin 1.5.17-1, I can't reproduce your `escape' failure against GNU make 3.81rc1. make: stat: p:foo: No medium found I was really amazed when I saw this. I don't think make should even *try* to read the status info of `p:foo' according to

[bug] (un)escaping problem in the makefile database output

2007-06-03 Thread Agent Zhang
Hi, there~ I've been fiddling about with the Makefile databases generated by 'make -pq' since I'm writing a gnu make runtime in pure Perl (in order to bootstrap my complete Perl rewrite of gmake easily). I've been assuming that the stuff generated by 'make -pg' is in valid gmake syntax and my

[bug #20067] Unescaped meta characters in makefile database outputs

2007-06-04 Thread Agent Zhang
URL: http://savannah.gnu.org/bugs/?20067 Summary: Unescaped meta characters in makefile database outputs Project: make Submitted by: agent Submitted on: Monday 06/04/2007 at 13:01 Severity: 3 - Normal Item

[bug #20069] Request for unexport/export info in makefile database outputs

2007-06-04 Thread Agent Zhang
URL: http://savannah.gnu.org/bugs/?20069 Summary: Request for unexport/export info in makefile database outputs Project: make Submitted by: agent Submitted on: Monday 06/04/2007 at 13:11 Severity: 3 - Normal

Re: [bug] (un)escaping problem in the makefile database output

2007-06-04 Thread Agent Zhang
On 6/4/07, Paul Smith [EMAIL PROTECTED] wrote: Feel free to file an enhancement request on Savannah to have this addressed. Already done in bug #20067 :) But I marked it as a bug instead of an enhancement. Sorry about that. Cheers, agentz ___

Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?

2007-06-19 Thread Agent Zhang
On 6/20/07, Stephan Beal [EMAIL PROTECTED] wrote: When a $(warning) or $(error) is inside a 'define', it is evaluated even if it is part of a comment. A demonstration: I think the test case to demonstrate this bug can be simplified as: define bogo # $(warning this should not happen) endef