bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH 2/2] Do not use DOS paths on Cygwin


From: Pavel Fedin
Subject: RE: [PATCH 2/2] Do not use DOS paths on Cygwin
Date: Thu, 08 Aug 2013 09:33:29 +0400

 Hello!

> Are you saying that if a Cygwin Make uses DOS style file names with
> drive letters, it also expects the PATH-style directory lists to use a
> semi-colon as a separator?  I don't think I'd expect that.

 There is a default in make.h:
--- cut ---
/* Handle other OSs.  */
#ifndef PATH_SEPARATOR_CHAR
# if defined(HAVE_DOS_PATHS)
#  define PATH_SEPARATOR_CHAR ';'
# elif defined(VMS)
#  define PATH_SEPARATOR_CHAR ','
# else
#  define PATH_SEPARATOR_CHAR ':'
# endif
#endif
--- cut ---
 But, i have just checked, it gets overridden by configure script. So if you
configure on Cygwin, it will be correct. But, well, i was talking about this
default actually.

 2 Cristopher: but it never allows both, this is simply impossible by
design.

> I think
> PATH-style lists should always use Unix-style file named in the Cygwin
> Make.  DOS-style file names should only be supported in targets and
> commands.

 Yes, of course. Cygwin runs unmodified UNIX scripts and makefiles, and they
would screw up badly if ';' is used.

> I know about MSYS, but building an MSYS version of Make is already a
> special procedure.  So I don't see why you should worry about that.

 I do not worry much, but i think a little about how this is done, because i
suggest that my modification should not make this special procedure even
more complicated. Don't you think so ?

 P.S. During testing Windows version of make i have found a little flaw in
make test suite. In test_driver.pl there is a 'toplevel' function, which
sets up environment for running make. And it has a list of env variables
which are propagated. Can you add Windows-specific TEMP and TMP to it ?
Without this Windows version fails back to '/' as temp directory, which
fails miserably on post-XP because accessing C:\ requires elevated
privilege.
 Sorry for not providing a .diff, but this is one-line fix, and approving it
is IMHO too much overhead.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia





reply via email to

[Prev in Thread] Current Thread [Next in Thread]