cmake update needed

cmake update needed

[Marco Atzeri]

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

[Tony Kelman]

> 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

[Tony Kelman]

> 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

Re: cmake update needed

[Warren Young]

> On Feb 4, 2015, at 3:40 PM, Tony Kelman <tony@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

[Tony Kelman]

> 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

[Yaakov Selkowitz]

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

[Tony Kelman]

> 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

[Yaakov Selkowitz]

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

Re: cmake update needed

[Tony Kelman]

> 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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: cmake update needed

[Marco Atzeri]

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

[Yaakov Selkowitz]

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

[Andrew Schulman]

> 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

[Tony Kelman]

> 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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: cmake update needed

[Tony Kelman]

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 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)
    {
    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.

-Tony

Re: cmake update needed

[Achim Gratz]

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

[Peter Rosin]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

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 #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: cmake update needed

[Yaakov Selkowitz]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]