X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Why are Windows paths broken in make 3.81?
Date: Mon, 24 Jul 2006 19:13:49 +0100
Message-ID: <01a401c6af4c$e9afb6a0$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <44C1796F.50308@netacquire.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 22 July 2006 02:04, Joachim Achtzehnter wrote:

> mwoehlke wrote:

>> Michael Hirsch wrote:

>>> Here is a sample Makefile that breaks with Gnu Make 3.81-1 under
>>> Cygwin, but works fine with Gnu Make 3.80-1.
>>>               [ ... snip ... ]
>>> Was this a deliberate break with backwards compatibility?  

>> Yes. See <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>.

> Unfortunately, many of us deal with huge cross-platform 3rd-party makefile
> collections that are partially auto-generated, sometimes even on-the-fly,

> I just had to deal with such a messy system and the new Cygwin make doesn't
> work. Even though this collection of makefiles was initially written on a
> POSIX system it still got into trouble with DOS paths because some of the
> tools it calls to generate makefiles return platform-specific paths. So
> this works fine on a POSIX system, worked fine on Win2000 with the old
> make, but now I had to understand complicated sed programs to add extra
> platform-specific sed transformations to convert paths returned by other
> cross-platform tools to something the new make accepts.
> 
> There was also some difference in newline handling which required another
> set of sed changes, arghh!
> 
> All of this was definitely inconvenient! And it was not caused by somebody
> putting non-POSIX paths in a makefile.

  Well, to be fair, it was caused by someone implementing a system that made
use of utilities that put non-POSIX paths in a makefile.  It didn't 'just
happen', it was the consequence of a deliberate set of design and
toolset-selection decisions.
 
> Of course, after fixing all this it still doesn't work, as mentioned in
> another post, make crashes with threadlist_ix -1, so I still have to go
> back to the older version, even after all the work. :-(

  Which begs the question: given that you were working on such a large and
complex makefile system, and given that it had non-POSIX paths in a makefile,
and given that it wasn't broke and didn't need fixing ...

...  why on EARTH did you deliberately go and upgrade to a new version of make
that doesn't support non-POSIX paths?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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