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
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 va
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, /p
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), the
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 i
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
> special-casing
> of Cygwin where usin
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.
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.
>
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
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-Oct
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 l
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
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 usef
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
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
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 packagi
> On Feb 4, 2015, at 3:40 PM, Tony Kelman 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 Dropbo
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 p
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
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.
21 matches
Mail list logo