X-Spam-Check-By: sourceware.org Date: Thu, 17 Aug 2006 09:59:30 -0400 (EDT) From: Igor Peshansky Reply-To: cygwin@cygwin.com To: Eli Zaretskii cc: cygwin@cygwin.com Subject: Re: change in behavior of make from 3.80 to 3.81 In-Reply-To: Message-ID: References: <6.2.3.4.2.20060815151104.0b40e260@pop.nycap.rr.com> <01b901c6c116$21259430$a501a8c0@CAM.ARTIMI.COM> <6.2.3.4.2.20060816091525.0ab90af0@pop.nycap.rr.com> <20060816144110.GX20467@calimero.vinschen.de> <6.2.3.4.2.20060816111421.0b446b60@pop.nycap.rr.com> <20060816155054.GY20467@calimero.vinschen.de> <6.2.3.4.2.20060816144036.09695af0@pop.nycap.rr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com 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... > and also adds a too-tight coupling between Make and the Cygwin file-name > handling (i.e., every change in how /cygdrive/ is handled in Cygwin will > require a corresponding change in Make). Not true. Cygwin has an API function for just this purpose, and all make has to do is call it. Any changes in /cygdrive and path handling will be reflected in that API function, and make will not need to be changed. In fact, with Cygwin being a DLL, it will not even need to be recompiled. > While these disadvantages are not a catastrophe, I don't see a need to > punish Make by them when a better and easier solution is available (i.e. > use the existing HAVE_DOS_PATHS code, perhaps with some Cygwin-specific > changes). FWIW, the Cygwin-specific changes to that code will have to essentially invoke the same functionality as above. > Contrary to what some people said in this thread, I don't see any > problems that could hamper the Cygwin build of Make if it supported > drive letters, since Windows doesn't allow colons anywhere else in file > names anyway. Actually, as Gareth mentioned, *Cygwin* allows colons in file names on managed mounts. So, at the very least there'd be confusion of whether c:\\TEMP is a directory TEMP in the root of the C: drive, or a file named 'c:\\TEMP' in the current directory on a managed mount... > Of course, the best way of making sure no problems exist is to test the > patched version in the Cygwin environment. Indeed. We're waiting for a volunteer to post a patch approved by the upstream make maintainers for testing. None so far. > > Although, with make using spaces to separate everything, I still don't > > see how this would work with absolute win32 paths in the general case. > > Whatever problems you have in mind, they afflict the Posix platforms > as well. The Windows ports (including the Cygwin port) do not need to > be better than the original, only not worse ;-) True. Thanks for your input. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha@cs.nyu.edu | igor@watson.ibm.com ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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/