This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: change in behavior of make from 3.80 to 3.81
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/