Date: Mon, 24 Jul 2006 16:13:38 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Why are Windows paths broken in make 3.81?
Message-ID: <20060724201338.GC23671@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <9c2aabaf0607211629u4e29ffa1w5f09b3d8e5a923fc AT mail DOT gmail DOT com> <e9rrqr$6ei$1 AT sea DOT gmane DOT org> <44C1796F DOT 50308 AT netacquire DOT com> <20060722222244 DOT GB18054 AT trixie DOT casa DOT cgf DOT cx> <44C4FF71 DOT 6050505 AT netacquire DOT com> <20060724184240 DOT GB21218 AT trixie DOT casa DOT cgf DOT cx> <44C5252F DOT 5040201 AT netacquire DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44C5252F.5040201@netacquire.com>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Mon, Jul 24, 2006 at 12:53:19PM -0700, Joachim Achtzehnter wrote:
>Christopher Faylor wrote:
>>Well, you *could* expect a fix if you provided enough details.
>
>Understood.  The question is, can there still be value in reporting
>that a program crashes, even with minimal but potentially still useful
>information?  I'm just asking and am genuinely interested in hearing
>the developers' preferences.

No.  Reports of "XYZ dies when I run a complicated program" are
worthless unless the reporter is willing to help track down the problem.

>If this kind of less-than-ideal problem report is considered to be
>always useless, which would come as a surprise to me because as a
>developer I've seen many cases where a report like this is all that was
>needed to highlight the problem,

I would be very very surprised if you were able to fix problems when
someone just mentions that their program crashes when they do something
complicated.  If that really was the case then you would just have to
say that to yourself before every release in order to fix problems.

>>It is pretty frustrating to see content-free bug reports like "there
>>was also some difference in newline handling"
>
>Please don't take this out of context again, I already explained that this 
>was an illustration of how breaking backward compatibility is inconvenient 
>for users.

I didn't take it out of context before and I am not doing so now.  I
trimmed the parts that I wanted to respond to, as is good internet
etiquette.  I wasn't the person who mentioned inconvenience and had no
interest in responding to that.  I was trying to get to the bottom of
something that seemed like it could be a bug.

>I saw references related to newline treatment in the changelog and
>proceeded to apply fixes to my third-party makefiles (not written by
>me) without even thinking of mentioning this on the list, but it
>definitely was inconvenient, and when somebody claimed otherwise I felt
>I had to respond as I did.

Now I understand that you are referring to documented changes in the GNU
Make NEWS file.  So, this observation was directed towards the upstream
maintainer who wrote:

  * WARNING: Backward-incompatibility!
    In order to comply with POSIX, the way in which GNU make processes
    backslash-newline sequences in command strings has changed.  If your
    makefiles use backslash-newline sequences inside of single-quoted
    strings in command scripts you will be impacted by this change.  See
    the GNU make manual subsection "Splitting Command Lines" (node
    "Splitting Lines"), in section "Command Syntax", chapter "Writing the
    Commands in Rules", for details.

and your report has nothing to do with standard cygwin newline
complaints, as I assumed.

I guess that means there is nothing more to discuss.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/