X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
X-IronPort-AV: E=McAfee;i="5200,2160,5341"; a="4866003"
Message-ID: <4880DC05.5030905@qualcomm.com>
Date: Fri, 18 Jul 2008 19:08:05 +0100
From: Rob Walker <rwalker AT qualcomm DOT com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: colons in Cygwin (was Re: make-3.81-3 (ITA??))
References: <487E8966 DOT 7020509 AT qualcomm DOT com> <20080717004748 DOT GA30298 AT ednor DOT casa DOT cgf DOT cx> <487FAB2D DOT 4000201 AT qualcomm DOT com> <487FAFD9 DOT 2030501 AT x-ray DOT at> <487FDBA9 DOT 2030909 AT qualcomm DOT com> <20080718083405 DOT GG5675 AT calimero DOT vinschen DOT de>
In-Reply-To: <20080718083405.GG5675@calimero.vinschen.de>
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-Id: <cygwin.cygwin.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

Corinna Vinschen wrote:
> On Jul 17 16:54, Rob Walker wrote:
>   
>> Reini Urban wrote:
>>     
>>> Colons in filenames are fine and will be supported with cygwin-1.7.
>>> But c:/ it will not map to the root of some c drive, it will map to the
>>> subdir "c:"
>>> For now we had to use managed mounts for such names, soon we will be
>>> able to see readable names.
>>>
>>>       
>> [RGW] This is interesting news to me.  This would break the planned GNU
>> make support for MSDOS paths under Cygwin, wouldn't it?  On which Windows
>> filesystems will this be useful?  In other words, where might one see a
>> directory named "c:" on a Windows box?
>>     
>
> Cygwin is a POSIX emulation layer in the first place.  That's what we
> are committed to in the first place.  Why would you want to use Win32
> paths in a POSIX environment, except as parameter to native Win32 tools?
>   

[RGW] This is exactly what I want it for.  Thing is, I don't want to 
know ahead of time whether the tool is Cygwin or not.  I'm counting on a 
small amount of interoperability.  More below...

> For dependency tracking in make there's no good reason to use the Win32
> path.

[RGW] I respect your opinion.  Let me offer mine:  I think several 
people have offered good reasons before on this list.  Our opinions 
aside: the reasons offered were good enough for the developers of make 
to offer this functionality in the mainline.

>   You can just as well use the POSIX equivalent.  If you have to
> convert between paths, there's the cygpath tool.
>   

[RGW] Yes, such a beast would be possible to construct, but it would be 
horribly inefficient.  I'd be wrapping every file parameter to every 
command with a call to cygpath.  It may be hard for you to imagine why 
I'd object to this, though, so here's some background:  our make system 
is quite large, and much the content of the makefiles is 
auto-generated.  We use it to compile or cross-compile some 30 flavors 
of our product, using a fairly even mixture of Windows and Cygwin 
tools.  The makefile generators are of the same even mix (e.g. we use 
compilers to generate .dep files).

The exact same make system is used to compile and cross compile on 
Linux, MacOS, and NetBSD.  The system works very well, with very few 
complaints from my team, our customers, and others who have used it.  
One of the most often heard complaints is that it's slow on Cygwin 
(because of the cost of exec).

-Rob


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