Message-ID: <44C4FF71.6050505@netacquire.com>
Date: Mon, 24 Jul 2006 10:12:17 -0700
From: Joachim Achtzehnter <joachima@netacquire.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: Why are Windows paths broken in make 3.81?
References: <9c2aabaf0607211629u4e29ffa1w5f09b3d8e5a923fc@mail.gmail.com> <e9rrqr$6ei$1@sea.gmane.org> <44C1796F.50308@netacquire.com> <20060722222244.GB18054@trixie.casa.cgf.cx>
In-Reply-To: <20060722222244.GB18054@trixie.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Hi all,

Christopher Faylor wrote:

> On Fri, Jul 21, 2006 at 06:03:43PM -0700, Joachim Achtzehnter wrote:
>> There was also some difference in newline handling which required another 
>> set of sed changes, arghh!
> 
> Well with detailed bug reports like this and the previous "make provides an
> error on one of my complex makefiles" we're surely well on the road towards
> perfection.

This sarcastic response to one sentence out of a much longer post quoted in 
isolation suggests that a clarification is in order. Neither of my previous 
posts, not the one about the "threadlist_ix -1" error and not the one I 
wrote specifically in response to a claim that the recent changes to make 
were "not an inconvenience", were written with any expectations for a fix. 
I do understand free software, I'm not paying anybody, hence I can have no 
expectation of somebody doing work for me.

I wrote the first post (about "threadlist_ix -1") in case this particular 
error message rings a bell given that the recent changes that must have 
caused it are likely fresh in the minds of developers, i.e. trying to be 
helpful. If it isn't anything obvious, clearly more detailed debugging 
would be needed, something that won't be altogether easy given that it 
occurs in makefiles that are complex and of which I know very little how 
everything works (lots of scripting to generate make rules on the fly, so 
it isn't even easy to see what the makefiles that ultimately get processed 
by make contain without a lot of sleuthing).

My second post was specifically in response to the claim by mwoehlke 
suggesting that the changes were "not an inconvenience". In this post all 
the issues I mentioned were intended as illustrations of such 
inconveniences, so there was even less implied expectation of somebody 
acting on these. Note, that I wrote that I had already addressed the issues 
caused by deliberate incompatibilities, all I intended to do was point out 
that it *had been* inconvenient.

So sum up, you are the people doing the work, I'm not funding your work, so 
all decisions are yours. You may or may not take into account that at least 
some users are likely to be inconvenienced by some of these decisions, and 
especially those using Cygwin as a tool for achieving cross-platform 
portability of large complex systems, of which they sometimes know very 
little (they will now have to understand more to get things working again).

Thanks for providing these tools, and thanks also to those who posted 
possible solutions for some of these issues. As I wrote, in this case I had 
already managed to address all issues related to the functional changes in 
make, only the internal error remains (and at present it is still easy to 
use the older make, which may change as we go forward).

Joachim

-- 
work:     joachima@netacquire.com   (http://www.netacquire.com)
private:  joachim@kraut.ca          (http://www.kraut.ca)

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