X-Spam-Check-By: sourceware.org
Message-ID: <44C1796F.50308@netacquire.com>
Date: Fri, 21 Jul 2006 18:03:43 -0700
From: Joachim Achtzehnter <joachima AT netacquire DOT com>
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> <e9rrqr$6ei$1 AT sea DOT gmane DOT org>
In-Reply-To: <e9rrqr$6ei$1@sea.gmane.org>
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: <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

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.
>> ...
>> Was this a deliberate break with backwards compatibility?  It means
>> that every single reference to a windows path needs to be wrapped in
>> cygpath, which is a huge inconvenience.
> 
> Yes. See <http://cygwin.com/ml/cygwin-announce/2006-07/msg00008.html>. 
> If you are using a POSIX-like "OS" (i.e. Cygwin), you should be using 
> POSIX paths. That's not an inconvenience, that's called writing a bad 
> makefile.

I would dispute the contention that this change is "not an inconvenience". 
It is a major inconvenience and the problems are not just due to "writing a 
bad makefile".

If one was just dealing with a bunch of small makefiles that one has 
"written" or could easily re-write it wouldn't be a big deal.

Unfortunately, many of us deal with huge cross-platform 3rd-party makefile 
collections that are partially auto-generated, sometimes even on-the-fly, 
i.e. commands in one makefile generate (portions of) other makefiles using 
tools like sed and invoking many subsidiary tools like IDL compilers and 
various pre-processors in the process.

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.

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. :-(

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/