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.
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,
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
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
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
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
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
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
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
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]
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]
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
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
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
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
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
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
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.
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
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
20 matches
Mail list logo
