Hi Will,
We reviewed this topic today during our merge-to-master meeting. Thanks
for working on this. These are good improvements. However, there are
two problems we noticed:
(1) The first patch http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=34ea1790
contains this hunk:
On 05/24/2011 03:04 PM, Will Dicharry wrote:
Brad King wrote:
Therefore if someone finds HDF5 twice the second time may take the wrong
logic path. The proper value to test after the find_package call is
HDF5_FOUND to know whether or not the config file was found and loaded.
Won't this have
I
have managed to resolve this issue. The problem was that I only ran
cmake once. Running it a second time before running mingw32-make
produced the correct results. I guess this has something to do with the
cache not having all the right values after just one run.
Stiaan
On 05/19/2011 05:53
Hi guys,
I just discovered the --warn-uninitialized flag to cmake, and in the
process found some really nasty bugs. Is there any way to enable this
from the CMakeLists.txt files? Is there a corresponding
--error-uninitialized value?
Thanks
/Johan
___
On 5/23/2011 2:15 PM, sind...@gmail.com wrote:
I have the below directory structure for Fortran code which has very
basic dependencies, I am not able to get CMake to recognize the
dependencies automatically without me explicitly having to specify it
using add_dependencies or
Hi Theodore,
Your observation is interesting, I had expected CMake to not remember function
definitions across subtrees similar to non-cached variables. Apparently, it
does not store function and macro definitions on a stack.
However, what you still could do is either one of the following or
On 05/23/2011 01:39 PM, Marcel Loose wrote:
On Mon, 2011-05-23 at 07:21 -0400, David Cole wrote:
On Mon, May 23, 2011 at 4:13 AM, Marcel Loose lo...@astron.nl wrote:
Hi all,
A colleague of mine reported a bug in our CMake-base build
system when
doing
Is there some other way that I can force CMake to find /usr/lib/
libuuid.so? Like if I included it as an external library?
Thanks,
Sara
On May 23, 2011, at 2:29 PM, Sara Rolfe wrote:
Hi Eric,
Yes, I believe it is a dependancy from ITK. I saw that wiki page
and at the time did not have
Update: I've attempted to add /usr/lib64/libuuid.so as an external
library, but am still getting the same error. When I run ccmake it
appears to find the location of the library. Below is my
CMakeLists.txt in case I have made any errors here:
cmake_minimum_required(VERSION 2.6)
On Tue, May 24, 2011 at 12:54 PM, Sara Rolfe smro...@u.washington.eduwrote:
Update: I've attempted to add /usr/lib64/libuuid.so as an external library,
but am still getting the same error. When I run ccmake it appears to find
the location of the library. Below is my CMakeLists.txt in case I
Hi David,
I get:
$ grep -i uuid CMakeCache.txt
LIBVAR:FILEPATH=/usr/lib64/libuuid.so
Sorry for the double email, I dropped the mailing list in the last one.
Thanks, Sara
On May 24, 2011, at 10:21 AM, David Cole wrote:
On Tue, May 24, 2011 at 12:54 PM, Sara Rolfe
smro...@u.washington.edu
Unfortunately, changing the variable name from LIBVAR to uuid does not
fix this issue, so it may be that it is not used as a variable? I now
get:
$ grep -i uuid CMakeCache.txt
libuuid:FILEPATH=/usr/lib64/libuuid.so
Thanks,
Sara
On May 24, 2011, at 10:21 AM, David Cole wrote:
the same
I was looking for the source of the issue. (Hoping that whoever was adding
uuid to the list of libraries would be caching a find result. Apparently
they are not.)
Which means that they are referencing this library either simply by name
(uuid) or by the incorrect full path in the list of libraries
I guess that's fair; but what appears to be happening is that it's
deleting the cache even if the -D compiler string is the same as
what's already in Cache.
On Mon, May 23, 2011 at 4:45 PM, David Cole david.c...@kitware.com wrote:
On Mon, May 23, 2011 at 5:37 PM, kent williams
I'm using InsightToolkit-3.14.0. I've used this installation from
another 64-bit machine successfully, so I had assumed it was ok. I
didn't build it myself so I'm not sure. Do you know how I can check
this?
Thanks,
Sara
On May 24, 2011, at 10:46 AM, David Cole wrote:
I was looking
I have also tried InsightToolkit-3.20.0 unsuccessfully.
Thanks,
Sara
On May 24, 2011, at 10:46 AM, David Cole wrote:
I was looking for the source of the issue. (Hoping that whoever was
adding uuid to the list of libraries would be caching a find result.
Apparently they are not.)
Which
I think re-asking this question over on the Insight Users list would be
appropriate. There's a much wider audience of Insight users (people building
applications just like this) on that list.
I'm sure there are people who have built 64-bit Linux programs using ITK and
VTK over there. There must
The Find.CUDA module returns 32bit libs on a 64bit platform, is this a bug
or what?
For example, in OpenMM, it returns:
/usr/local/cuda/lib/libcublas.so
/usr/local/cuda/lib/libcufft.so
On an Ubuntu 10.04 amd64 platform with a 64bit install of the nVidia driver
and software, i.e.:
$ ls
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 7ffb678e4bc4eae1bf747d2ba9d3561c6d09b03a (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via da1b6883253fc8426b41734e4b23d5839a510529 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 1605784f470c46062e166abdf8a1c634068a53c4 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 14a6bda1a248ae5a7926d8bf25ce3faa37c2df91 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 0f843584f32132969ea1c9f11970af1ea6adabc9 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 44b7f2f5bcdafaed0723d293d9aa5029cc5dd06c (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via c5e00bf0b25fb816a80215c4c110d319c6cce079 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 8b17fd67256d10c86acba9c2b2ce1d0211a90fea (commit)
from
26 matches
Mail list logo
