This is the mail archive of the
mailing list for the Cygwin project.
Re: cmake update needed
- From: "Tony Kelman" <tony at kelman dot net>
- To: <cygwin-apps at cygwin dot com>
- Date: Fri, 6 Feb 2015 03:04:27 -0800
- Subject: Re: cmake update needed
- Authentication-results: sourceware.org; auth=none
- References: <54D1F25E dot 20701 at gmail dot com> <BAY169-DS1438076617CAC9B60DFC2CA73A0 at phx dot gbl> <1423093749 dot 596 dot 11 dot camel at cygwin dot com> <BAY169-DS20D64B9DEEF05161FF6EEFA73B0 at phx dot gbl> <1423107612 dot 596 dot 24 dot camel at cygwin dot com> <BAY169-DS2928D017F1DAC36EBB51CA73B0 at phx dot gbl> <1423133897 dot 596 dot 29 dot camel at cygwin dot com> <BAY169-DS2660AB4CCF4A4D033C82F7A7380 at phx dot gbl> <20150206093828 dot GC1035 at calimero dot vinschen dot de>
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.
> Second, it corrects some /proc/cpuinfo, /proc/meminfo, etc
> 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 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.
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. It's not the task of the application to second-guess the
underlying "OS" (Cygwin taking the role in a way).
There are various wrapper scripts in autotools to do the same thing
(use Cygwin as a build environment for non-Cygwin compilers), they just
tend to make decisions on what kinds of path translation to do based on
`uname` rather than compile-time #ifdef's. Though with CMake, users can
always have the option of using the binary installer downloads and
running those from within Cygwin. So the Cygwin-distributed build of
cmake has a bit more room to follow Cygwin best practices, at the cost
of not supporting as many use cases, and requiring local patches that
need to be kept updated.
Cygwin's access() call is not for POSIX paths only.
It handles native Windows paths as well.
Oh cool, I was not aware of that.
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)
if(in_name == ':')
if(in_name == '\\')
instead using the Unix condition of false if len < 1, true if
in_name == '~' 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