X-Spam-Check-By: sourceware.org From: "Dave Korn" To: Subject: RE: change in behavior of make from 3.80 to 3.81 Date: Thu, 17 Aug 2006 15:16:31 +0100 Message-ID: <00e701c6c207$bcf80bd0$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: Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: 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 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'. 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/