On Feb 5 21:41, Tony Kelman wrote: > >Do you have any specific questions? > [...] > Second, it corrects some /proc/cpuinfo, /proc/meminfo, etc special-casing > of Cygwin where using the same code as Linux should work. Makes sense, > I'll split this out so it can be discussed on its own w/upstream.
Would be nice to learn the details. Maybe we can tweak this in Cygwin for the future...? > Lastly, it's disabling handling of Windows paths, and conversion from > Cygwin paths to Windows paths. It does look like PathCygwinToWin32 could > go away if the only place it's used in FileExists is changed to just use > access(). Upstream might find this and the change to FileIsFullPath > debatable though, since a use case for a decent number of people is > running cmake within Cygwin to drive non-Cygwin compilers. Should we > really ignore this use case? Yes. It's not the task of the application to second-guess the underlying "OS" (Cygwin taking the role in a way). Cygwin's access() call is not for POSIX paths only. It handles native Windows paths as well. As for FileIsFullPath, what is the change about? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpOGxuHDHxiC.pgp
Description: PGP signature