Re: cmake update needed
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
Re: cmake update needed
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
Re: cmake update needed
Tony Kelman writes: 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. Well, they should simply ask via nproc from coreutils. The cpuinfo format looks very different across different architectures anyway. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: cmake update needed
On 2015-02-06 12:04, Tony Kelman wrote: 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 For Libtool, the reason is that the heuristic in MSYS can't be trusted to do path translations in the correct places. So, there is infrastructure in place to do explicit path translation for MSYS, and piggy-backing on that to use cygpath for explicit path translation when using Cygwin to drive Win32 tools (such as MSVC) was a small detail. On Cygwin, that path translation infrastructure is completely bypassed, unless you ask for it at configure time. The only case where it's on-by-default is MSYS (where you'll need it). Cheers, Peter
Re: cmake update needed
On Feb 6 12:45, Corinna Vinschen wrote: On Feb 6 03:04, Tony Kelman wrote: 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. ...and just uploaded new Cygwin snapshots to https://cygwin.com/snapshots/ which provide the physical id and cpu cores info for Intel now, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2YMLBe5IFb.pgp Description: PGP signature
Re: cmake update needed
On Thu, 2015-02-05 at 21:41 -0800, Tony Kelman wrote:
Do you have any specific questions?
2.8.9-perl-libs.patch AIUI changes PERL_POSSIBLE_LIBRARY_NAMES from
being set to perl{PERL_VERSION_STRING} perl only when the command
`${PERL_EXECUTABLE} -V:libperl` fails, to appending those values any
time PERL_EXECUTABLE is found. Is that command expected to fail in some
circumstances where one would be building a perl library? Or is the
problem that cmake find_library has trouble with the cyg* library prefix?
IIRC the latter.
2.8.12-gui-qt4, 2.8.12-opengl, 2.8.12-ruby, and 2.8.12-tclsh look pretty
straightforward and worth upstreaming. Should I assume you have not yet
tried to do so?
Correct.
#-cygwin.patch, which I had to rebase a few times to apply to the latest
release, does multiple things (good sign it should have been split into
multiple patches):
First, it disables case-insensitive matching. I see that there are some
non-default/experimental ways of running Cygwin in case sensitive mode,
but that is a runtime configuration. Most users are probably running with
case-insensitive default NTFS. If this change fixes more issues than it
causes I can take your word on it, but this would be hard to convince
upstream about. Is case sensitive matching really the right build-time
behavior to choose for Cygwin's cmake package?
Yes, cmake should leave that to Cygwin to handle. There are (or have
been) a few cases where a package bundles a cmake module with the same
name as a builtin one but with different case and different contents.
With case sensitivity on (as I do), the correct module should be chosen.
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.
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?
Corinna has already explained this.
--
Yaakov
Re: cmake update needed
Do you have any specific questions?
2.8.9-perl-libs.patch AIUI changes PERL_POSSIBLE_LIBRARY_NAMES from
being set to perl{PERL_VERSION_STRING} perl only when the command
`${PERL_EXECUTABLE} -V:libperl` fails, to appending those values any
time PERL_EXECUTABLE is found. Is that command expected to fail in some
circumstances where one would be building a perl library? Or is the
problem that cmake find_library has trouble with the cyg* library prefix?
2.8.12-gui-qt4, 2.8.12-opengl, 2.8.12-ruby, and 2.8.12-tclsh look pretty
straightforward and worth upstreaming. Should I assume you have not yet
tried to do so?
#-cygwin.patch, which I had to rebase a few times to apply to the latest
release, does multiple things (good sign it should have been split into
multiple patches):
First, it disables case-insensitive matching. I see that there are some
non-default/experimental ways of running Cygwin in case sensitive mode,
but that is a runtime configuration. Most users are probably running with
case-insensitive default NTFS. If this change fixes more issues than it
causes I can take your word on it, but this would be hard to convince
upstream about. Is case sensitive matching really the right build-time
behavior to choose for Cygwin's cmake package?
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.
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?
Thanks,
Tony
Re: cmake update needed
On Feb 4 12:45, Tony Kelman wrote: Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Happy to adopt it. Super, thanks a lot. I added you to cmake in cygwin-pkg-maint, so, whenever you're ready, feel free to upload. Downside: You have to accept a goldstar ;) POW hit-and-run gold star at http://cygwin.com/goldstars/#TK
Re: cmake update needed
On Feb 4 12:45, Tony Kelman wrote: Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Happy to adopt it. Super, thanks a lot. I added you to cmake in cygwin-pkg-maint, so, whenever you're ready, feel free to upload. Downside: You have to accept a goldstar ;) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpgC8MSp14VO.pgp Description: PGP signature
Re: cmake update needed
On Wed, 2015-02-04 at 22:37 -0800, Tony Kelman wrote: Given our past experience[1][2] in working with upstream, anyone who maintains a working cmake is going to have to carry patches long-term, if not permanently. [1] http://www.cmake.org/Bug/view.php?id=10122 [2] http://www.cmake.org/pipermail/cmake/2010-October/040353.html and thread Yes, those took a while, but they were resolved eventually. With far too much time and effort expended, something I'm not eager to repeat. All these patches are the result of years of real-world usage of cmake, and there will likely be more patches required in the future. I can't tell you off the top of my head which packages require each of these changes, but I can tell you why they are necessary (and a few of them should be quite obvious). That would help. Someone else is welcome to maintain the package without asking any questions, but if I'm going to do it I'd like to know what those patches are for. I have your git history, but your commit messages are not particularly enlightening. I'm asking for failure cases, links to bug reports or previous postings, or similar. I don't think that's an unreasonable request, is it? I'll put the patches back and rebuild, but I'd like to understand them first. As I said, I can't tell you any more which packages failed without these packages. Half of the patches should be obvious. Do you have any specific questions? -- Yaakov
Re: cmake update needed
On 2/5/2015 7:37 AM, Tony Kelman wrote: Given our past experience[1][2] in working with upstream, anyone who maintains a working cmake is going to have to carry patches long-term, if not permanently. [1] http://www.cmake.org/Bug/view.php?id=10122 [2] http://www.cmake.org/pipermail/cmake/2010-October/040353.html and thread Yes, those took a while, but they were resolved eventually. yes, it took a bit of diplomacy and a lot of patience. I recommend the same for the future. All these patches are the result of years of real-world usage of cmake, and there will likely be more patches required in the future. I can't tell you off the top of my head which packages require each of these changes, but I can tell you why they are necessary (and a few of them should be quite obvious). That would help. Someone else is welcome to maintain the package without asking any questions, but if I'm going to do it I'd like to know what those patches are for. I have your git history, but your commit messages are not particularly enlightening. I'm asking for failure cases, links to bug reports or previous postings, or similar. I don't think that's an unreasonable request, is it? I'll put the patches back and rebuild, but I'd like to understand them first. More easy to convince upstream if you know that also. -Tony Thanks for taking over Marco
Re: cmake update needed
Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Happy to adopt it. I have some builds of latest 3.1.1 sitting around that I can send to the list later today. Note that I have temporarily removed all of the patches from cygwin-ports since none of them were necessary to build, or changed the results of any of cmake's unit tests. I'll definitely put any of them back if I can get a reproducible test case report, to pursue with upstream for adding new cases to their unit tests. -Tony
Re: cmake update needed
Given our past experience[1][2] in working with upstream, anyone who maintains a working cmake is going to have to carry patches long-term, if not permanently. [1] http://www.cmake.org/Bug/view.php?id=10122 [2] http://www.cmake.org/pipermail/cmake/2010-October/040353.html and thread Yes, those took a while, but they were resolved eventually. All these patches are the result of years of real-world usage of cmake, and there will likely be more patches required in the future. I can't tell you off the top of my head which packages require each of these changes, but I can tell you why they are necessary (and a few of them should be quite obvious). That would help. Someone else is welcome to maintain the package without asking any questions, but if I'm going to do it I'd like to know what those patches are for. I have your git history, but your commit messages are not particularly enlightening. I'm asking for failure cases, links to bug reports or previous postings, or similar. I don't think that's an unreasonable request, is it? I'll put the patches back and rebuild, but I'd like to understand them first. -Tony
Re: cmake update needed
By “adopt,” you are offering to participate in the package contribution system, which involves a bit more than just putting tarballs in a shared Dropbox folder: https://cygwin.com/setup.html I'm aware, thanks, I already maintain 4 other packages. I'm putting these up for review of the packaging, as is customary. -Tony
Re: cmake update needed
Obviously the patches to the modules won't affect the build of cmake itself, but they do affect the building of other packages using cmake. These patches were all added over years of testing and usage, and are required for a useful cmake package. Sure. Were the reasons for them ever written down? If I'm going to maintain the package, I do not want to carry local patches forever. CMake's test suite is very extensive, if it's missing use cases that are specific to Cygwin then I'm sure upstream would be willing to add add more tests to catch them in the future. I'm willing to pursue upstreaming the patches wherever possible, but need test cases to do so. I've made this request once or twice before and it was ignored. -Tony
Re: cmake update needed
On Wed, 2015-02-04 at 12:45 -0800, Tony Kelman wrote: Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Happy to adopt it. I have some builds of latest 3.1.1 sitting around that I can send to the list later today. Note that I have temporarily removed all of the patches from cygwin-ports since none of them were necessary to build, or changed the results of any of cmake's unit tests. I'll definitely put any of them back if I can get a reproducible test case report, to pursue with upstream for adding new cases to their unit tests. Obviously the patches to the modules won't affect the build of cmake itself, but they do affect the building of other packages using cmake. These patches were all added over years of testing and usage, and are required for a useful cmake package. -- Yaakov
Re: cmake update needed
Happy to adopt it. I have some builds of latest 3.1.1 sitting around
that I can send to the list later today. Note that I have temporarily
removed all of the patches from cygwin-ports since none of them were
necessary to build, or changed the results of any of cmake's unit
tests. I'll definitely put any of them back if I can get a
reproducible test case report, to pursue with upstream for adding new
cases to their unit tests.
BASEURL=https://dl.dropboxusercontent.com/u/8244638/cygwin-cmake
wget --no-check-certificate --no-host-directories \
--force-directories --cut-dirs=2 \
${BASEURL}/i686/cmake-3.1.1-1.tar.xz \
${BASEURL}/i686/cmake-3.1.1-1-src.tar.xz \
${BASEURL}/i686/setup.hint \
${BASEURL}/i686/cmake-debuginfo/cmake-debuginfo-3.1.1-1.tar.xz \
${BASEURL}/i686/cmake-debuginfo/setup.hint \
${BASEURL}/i686/cmake-doc/cmake-doc-3.1.1-1.tar.xz \
${BASEURL}/i686/cmake-doc/setup.hint \
${BASEURL}/i686/cmake-gui/cmake-gui-3.1.1-1.tar.xz \
${BASEURL}/i686/cmake-gui/setup.hint \
${BASEURL}/i686/emacs-cmake/emacs-cmake-3.1.1-1.tar.xz \
${BASEURL}/i686/emacs-cmake/setup.hint \
${BASEURL}/x86_64/cmake-3.1.1-1.tar.xz \
${BASEURL}/x86_64/cmake-3.1.1-1-src.tar.xz \
${BASEURL}/x86_64/setup.hint \
${BASEURL}/x86_64/cmake-debuginfo/cmake-debuginfo-3.1.1-1.tar.xz \
${BASEURL}/x86_64/cmake-debuginfo/setup.hint \
${BASEURL}/x86_64/cmake-doc/cmake-doc-3.1.1-1.tar.xz \
${BASEURL}/x86_64/cmake-doc/setup.hint \
${BASEURL}/x86_64/cmake-gui/cmake-gui-3.1.1-1.tar.xz \
${BASEURL}/x86_64/cmake-gui/setup.hint \
${BASEURL}/x86_64/emacs-cmake/emacs-cmake-3.1.1-1.tar.xz \
${BASEURL}/x86_64/emacs-cmake/setup.hint
-Tony
cmake update needed
Hi, I am starting to find programs with CMake Error at CMakeLists.txt:1 (cmake_minimum_required): CMake 2.8.10 or higher is required. You are running version 2.8.9 no problem (yet) on 64 bit but on 32bit yes. 2.8.9 package was released 2.5 years ago, and the 64bit version is due to Yaakov. Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Regards Marco
Re: cmake update needed
On Feb 4, 2015, at 3:40 PM, Tony Kelman t...@kelman.net wrote: Happy to adopt it. BASEURL=https://dl.dropboxusercontent.com/u/8244638/cygwin-cmake By “adopt,” you are offering to participate in the package contribution system, which involves a bit more than just putting tarballs in a shared Dropbox folder: https://cygwin.com/setup.html
Re: cmake update needed
On Wed, 2015-02-04 at 16:08 -0800, Tony Kelman wrote: Obviously the patches to the modules won't affect the build of cmake itself, but they do affect the building of other packages using cmake. These patches were all added over years of testing and usage, and are required for a useful cmake package. Sure. Were the reasons for them ever written down? If I'm going to maintain the package, I do not want to carry local patches forever. Given our past experience[1][2] in working with upstream, anyone who maintains a working cmake is going to have to carry patches long-term, if not permanently. [1] http://www.cmake.org/Bug/view.php?id=10122 [2] http://www.cmake.org/pipermail/cmake/2010-October/040353.html and thread CMake's test suite is very extensive, if it's missing use cases that are specific to Cygwin then I'm sure upstream would be willing to add add more tests to catch them in the future. I'm willing to pursue upstreaming the patches wherever possible, but need test cases to do so. I've made this request once or twice before and it was ignored. All these patches are the result of years of real-world usage of cmake, and there will likely be more patches required in the future. I can't tell you off the top of my head which packages require each of these changes, but I can tell you why they are necessary (and a few of them should be quite obvious). -- Yaakov
