Re: cmake update needed

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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

Attachment: pgpR82TjH09BQ.pgp
Description: PGP signature