X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: change in behavior of make from 3.80 to 3.81
Date: Thu, 17 Aug 2006 15:51:01 +0100
Message-ID: <00f301c6c20c$8e864c80$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20060817144633.GF17328@trixie.casa.cgf.cx>
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 17 August 2006 15:47, Christopher Faylor wrote:

> On Thu, Aug 17, 2006 at 03:16:31PM +0100, Dave Korn wrote:
>> On 17 August 2006 15:13, Igor Peshansky wrote:
>> 
>>> On Thu, 17 Aug 2006, Igor Peshansky wrote:
>>> 
>>>> On Thu, 17 Aug 2006, Eli Zaretskii wrote:
>>>> 
>>>>>> On Wed, 16 Aug 2006, Igor Peshansky wrote:
>>>>>> 
>>>>>> Alternatively, you can try to implement a $(cygpath ...) function in
>>>>>> make and submit *that* to the upstream maintainers.
>>>>> 
>>>>> FWIW, I don't think such a function is a good idea, and if it is
>>>>> proposed on the Make mailing list, I will probably object to it.
>>>>> 
>>>>> The reason is that adding such a function goes against portability of
>>>>> Makefiles across different ports of Make,
>>>> 
>>>> ...which you would already have with cl commands and DOS paths...
>>> 
>>> Actually, sorry, I've misread the above.  Doesn't GNU make already have a
>>> plethora of functions not present in other makes?  What's wrong with one
>>> more?  If "cygpath" is too system-specific a name, let's pick one that
>>> isn't ("pathconv"?).
>> 
>> 
>>  And I was going to point out that it could simply be a no-op on any other
>> platform and, as you say, a dll call on cygwin that hides make from being
>> exposed to any 'black magic'.
> 
> I don't know.  I think I agree with Eli here.
> 
> The thought of adding a cygwin-specific function to make and then making
> sure that it exists as a noop in any other version of make seems a little
> pushy to me.

  Well, it could always just not exist, and people can hide it in wrapper
funcs or ifdefs.

  I'm certainly going to do it in my local toolchain though, because I reckon
it'll save a vast amount of time in a big project when I don't have to invoke
an external cygpath process for every file in the project.  Less subprocess
invocations == faster makefiles.

    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/