On Feb 6 03:04, Tony Kelman wrote: > Thanks for your input and taking an interest in the specifics Corinna. > Coincidentally upstream just released 3.1.2, so I may as well build and > upload that version with the patches added back in.
Sounds good.
> >> 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...?
>
> Looking closer at Source/kwsys/SystemInformation.cxx, now I'm not as sure.
> Without the patch, the special-case behavior for Cygwin is looking for
> "cpu count" in /proc/cpuinfo,
Which doesn't exist anymore for some time. This code should go away.
> which I don't see on my machine. The Linux
> code that the patch switches to look for "physical id" and "cpu cores,"
> which I also don't see.
Ouch! This is a bug in Cygwin. The information is available, it's
just printed only for AMD CPUs for some reason. I guess it's about the
age of this code snippet...
I just applied a fix for that.
> The changes to read "MemTotal:" and "MemFree:" from /proc/meminfo,
> "VmRSS:" from /proc/self/status, and having GetProcessId() use getpid()
> instead of returning -1 should work fine though.
Yes.
> >As for FileIsFullPath, what is the change about?
>
> The change disables the following snippet of code for the Cygwin case:
>
> // On Windows, the name must be at least two characters long.
> if(len < 2)
> {
> return false;
> }
> if(in_name[1] == ':')
> {
> return true;
> }
> if(in_name[0] == '\\')
> {
> return true;
> }
>
> instead using the Unix condition of false if len < 1, true if
> in_name[0] == '~' or '/', false otherwise. The (len < 2) part is
> obviously wrong for Cygwin, but this function isn't using access() so
> the change would make this function no longer return true for C:\ style
> Windows paths or UNC paths. A Cygwin application should probably be
> given those paths in /cygdrive/c/ form, but I'm not sure of all the
> places in cmake's code where this function gets used and what the
> consequences are.
Can you check? I guess some revamped cygwin code would be accepted
upstream, given time...
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgph5L9UgAPrK.pgp
Description: PGP signature
