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

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

[bug #20133] 'make -p' always uses ':=' for pattern-specific variable assignments

URL: Summary: 'make -p' always uses ':=' for pattern-specific variable assignments Project: make Submitted by: agent Submitted on: Saturday 06/09/2007 at 17:37 Severity: 3 - Normal

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

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

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

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

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

URL: 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] (un)escaping problem in the makefile database output

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 hyb

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

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 t

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

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

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

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 verst

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

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

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

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

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

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 w

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

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 Bourn