[CMake] Find.CUDA for /usr/local/cuda/lib64

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 /usr/loca

Re: [CMake] Handle lib64 library on Linux

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 be

Re: [CMake] Handle lib64 library on Linux

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 mea

Re: [CMake] Handle lib64 library on Linux

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 for

Re: [CMake] Setting CMAKE_C_COMPILER CMAKE_CXX_COMPILER Deletes Cache?

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 wrote: > On Mon, May 23, 2011 at 5:37 PM, kent williams > wrote: >> >> Ran into this with CMak

Re: [CMake] Handle lib64 library on Linux

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 librarie

Re: [CMake] Handle lib64 library on Linux

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 v

Re: [CMake] Handle lib64 library on Linux

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 wrote: Update: I've attemp

Re: [CMake] Handle lib64 library on Linux

On Tue, May 24, 2011 at 12:54 PM, Sara Rolfe wrote: > 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

Re: [CMake] Handle lib64 library on Linux

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) PROJECT(G

Re: [CMake] Handle lib64 library on Linux

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 t

Re: [CMake] Parallel build & test problem

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 wrote: >> Hi all, >> >> A colleague of mine reported a bug in our CMake-base build >> system when >> doing a

Re: [CMake] Double redefinition of commands...

I just realized that the second solution has one flaw. You will need to reset the guard variable in the root CMakeLists.txt file via set (CUSTOM_COMMANDS_INCLUDED 0 CACHE INTERNAL "" FORCE) --Andreas On May 24, 2011, at 10:37 AM, Andreas Schuh wrote: > Hi Theodore, > > Your observation is int

Re: [CMake] Double redefinition of commands...

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 ma

Re: [CMake] Automatically Detecting Basic Fortran Dependencies

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 target_link_lib

[CMake] Error on uninitialized vars?

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 ___ Po

Re: [CMake] [SOLVED] Incorrect extra MinGW link flags

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 P