X-Spam-Check-By: sourceware.org Message-ID: <44C4FF71.6050505@netacquire.com> Date: Mon, 24 Jul 2006 10:12:17 -0700 From: Joachim Achtzehnter User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Why are Windows paths broken in make 3.81? References: <9c2aabaf0607211629u4e29ffa1w5f09b3d8e5a923fc AT mail DOT gmail DOT com> <44C1796F DOT 50308 AT netacquire DOT com> <20060722222244 DOT GB18054 AT trixie DOT casa DOT cgf DOT cx> In-Reply-To: <20060722222244.GB18054@trixie.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT 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 AT netacquire DOT com (http://www.netacquire.com) private: joachim AT kraut DOT 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/