Re: [CMake] FORTRAN and BLAS Issue

2012-05-03 Thread Tim Gallagher 
You're not using the results of the find_package. 

It should look like: 

cmake_minimum_required(VERSION 2.8) 
project(collision) 
enable_language(Fortran) 
FIND_PACKAGE(BLAS REQUIRED) 
add_definitions(-O3) 
add_executable(collision test.f90) 
target_link_libraries(collision ${BLAS_LIBRARIES}) 

Also, the add_definitions shouldn't really be used for things like -O3, it 
should be used for things like -DMY_FLAG or something. Flags like -O3 should be 
added to the CMAKE_Fortran_FLAGS. 

Tim 

- Original Message -

From: "Matthew Clay"  
To: cmake@cmake.org 
Sent: Thursday, May 3, 2012 11:25:23 PM 
Subject: [CMake] FORTRAN and BLAS Issue 

Fellow cmake users: 

I am experiencing a minor issue with cmake, and can't seem to find an answer 
browsing the web. I have a minimal working example that highlights the issue 
with my main code. The problem is this: compiling by myself with gfortran and 
the appropriate flags produces no errors, while attempting to build the code 
with cmake throws an error. 

The FORTRAN code--note that DDOT is the call to BLAS that I want to make: 

PROGRAM TEST 
IMPLICIT NONE 
DOUBLE PRECISION,DIMENSION(2) :: x,y ! The two vectors. 
REAL(KIND=8),EXTERNAL :: DDOT ! Their dot product. 
x(:) = (/ 1.,100. /) 
y(:) = (/ 1.,1. /) 
WRITE (*,*) DDOT(2,x,1,y,1) 
END PROGRAM TEST 

What works: 

gfortran test.f90 -O3 -lblas 
./a.out 

What doesn't work: 

cmake_minimum_required(VERSION 2.8) 
project(collision) 
enable_language(Fortran) 
FIND_PACKAGE(BLAS REQUIRED) 
add_definitions(-O3 -lblas) 
add_executable(collision test.f90) 

Upon attempting [ mkdir build && cd build && cmake .. && make ] as with any 
other code I get the following result: 

Scanning dependencies of target collision 
[100%] Building Fortran object CMakeFiles/collision.dir/test.f90.o 
Linking Fortran executable collision 
CMakeFiles/collision.dir/test.f90.o: In function `MAIN__': 
test.f90:(.text+0x7d): undefined reference to `ddot_' 
collect2: error: ld returned 1 exit status 
make[2]: *** [collision] Error 1 
make[1]: *** [CMakeFiles/collision.dir/all] Error 2 

It appears that BLAS is not being linked with the code...maybe? I am not a 
cmake expert, and would greatly appreciate any words of wisdom for 
troubleshooting this problem! 

Thanks, 
Matt 

-- 

Powered by www.kitware.com 

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html 

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ 

Follow this link to subscribe/unsubscribe: 
http://www.cmake.org/mailman/listinfo/cmake 
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] FORTRAN and BLAS Issue

2012-05-03 Thread Matthew Clay 

Fellow cmake users:

I am experiencing a minor issue with cmake, and can't seem to find an 
answer browsing the web. I have a minimal working example that 
highlights the issue with my main code. The problem is this: compiling 
by myself with gfortran and the appropriate flags produces no errors, 
while attempting to build the code with cmake throws an error.


The FORTRAN code--note that DDOT is the call to BLAS that I want to make:

PROGRAM TEST
  IMPLICIT NONE
  DOUBLE PRECISION,DIMENSION(2) :: x,y  ! The two vectors.
  REAL(KIND=8),EXTERNAL :: DDOT ! Their dot product.
  x(:) = (/ 1.,100. /)
  y(:) = (/ 1.,1. /)
  WRITE (*,*) DDOT(2,x,1,y,1)
END PROGRAM TEST

What works:

gfortran test.f90 -O3 -lblas
./a.out

What doesn't work:

cmake_minimum_required(VERSION 2.8)
project(collision)
enable_language(Fortran)
FIND_PACKAGE(BLAS REQUIRED)
add_definitions(-O3 -lblas)
add_executable(collision test.f90)

Upon attempting [ mkdir build && cd build && cmake .. && make ] as with 
any other code I get the following result:


Scanning dependencies of target collision
[100%] Building Fortran object CMakeFiles/collision.dir/test.f90.o
Linking Fortran executable collision
CMakeFiles/collision.dir/test.f90.o: In function `MAIN__':
test.f90:(.text+0x7d): undefined reference to `ddot_'
collect2: error: ld returned 1 exit status
make[2]: *** [collision] Error 1
make[1]: *** [CMakeFiles/collision.dir/all] Error 2

It appears that BLAS is not being linked with the code...maybe? I am not 
a cmake expert, and would greatly appreciate any words of wisdom for 
troubleshooting this problem!


Thanks,
Matt
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Running Python unit tests importing modules built in CMake

2012-05-03 Thread Lori A. Pritchett-Sheats 



The ENVIRONMENT property worked for me. Thank you!

And I will look at the python virtual environment.


On 05/03/12 07:12, Bradley Lowekamp wrote:

Hello,

For testing python another alternative is to create a python virtual 
environment and install you python package into that. Here is an 
example of how I have done that:


https://github.com/SimpleITK/SimpleITK/blob/master/Wrapping/CMakeLists.txt#L97

Brad

On May 2, 2012, at 9:26 PM, David Cole wrote:


Are you using "add_test" to add the tests in the CMakeLists file?

If so, you can set the test ENVIRONMENT property to set PYTHONPATH
when ctest executes the test. See property doc here:

http://cmake.org/cmake/help/v2.8.8/cmake.html#prop_test:ENVIRONMENT


On Wed, May 2, 2012 at 5:17 PM, Lori A. Pritchett-Sheats
mailto:lpri...@lanl.gov>> wrote:

I'm building Python modules using SWIG and CMake, and have run into a
problem running Python unit tests for these built modules. I can not 
find a
slick way to set the Python module search path when running the 
test. The
usual trick of setting sys.path in the scripts will not work here 
because I

don't know the location of the build directory. I've tried updating
PYTHONPATH in my CMakeList.txt file but that change isn't picked up 
when the
test is executed. I could create the unit test modules at build time 
using
CONFIGURE_FILE replacing @CMAKE_CURRENT_BINARY_DIR@ in a sys.path 
line, but

that seems heavy-handed. Has anyone else run into this problem and found
better a solution?

--
Lori A. Pritchett-Sheats, PhD.
CCS-2, Computational Physics and Methods
Office: 505-665-6675
Fax: 505-665-4972

Los Alamos National Laboratory
P.O. Box 1663
MS D413
Los Alamos, NM 87544

--

Powered by www.kitware.com 

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com 

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html


Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ


Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake




Bradley Lowekamp

Medical Science and Computing for

Office of High Performance Computing and Communications

National Library of Medicine

blowek...@mail.nih.gov 







--
Lori A. Pritchett-Sheats, PhD.
CCS-2, Computational Physics and Methods
Office: 505-665-6675
Fax: 505-665-4972

Los Alamos National Laboratory
P.O. Box 1663
MS D413
Los Alamos, NM 87544

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Why does CMAKE_FIND_FRAMEWORK always default to FIRST ignoring command line definitions?

2012-05-03 Thread Charlie Sharpsteen 

Rolf Eike Beer wrote
> 
> Because those value is set in the Darwin platform file 
> (Modules/Platform/Darwin.cmake) which is taken into account by the
> PROJECT() 
> call. So this is just overridden.
> 
> Eike
> 

Any reason those definitions can't be protected by `IF(NOT DEFINED
CMAKE_FIND_FRAMEWORK)`? If I can't override the default from the command
line, it seems like the only recourse is to maintain patches for every
project I am trying to build with CMake--a very messy and fragile solution.

-Charlie

--
View this message in context: 
http://cmake.3232098.n2.nabble.com/Why-does-CMAKE-FIND-FRAMEWORK-always-default-to-FIRST-ignoring-command-line-definitions-tp7521759p7524847.html
Sent from the CMake mailing list archive at Nabble.com.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Using CMake with ifort compiler

2012-05-03 Thread Patrick Spendrin 
Am 03.05.2012 16:26, schrieb Alain Leblanc:
> The cmake documentation for add_subdirectory() states that the
> CMakeLists files in the subdirectories should contain their own
> project() command invocation. Your build file in the subdirectory does
> not contain one. I don't know that it will be automatically be seen by
> CMake as a fortran project because this is what the project in the top
> directory is.
> 

You're supposed to add another project() call in the subdirectory only
if you use EXCLUDE_FROM_ALL and not in general.

regards,
Patrick
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] variable inheritance

2012-05-03 Thread Patrick Spendrin 
Am 03.05.2012 16:21, schrieb David Cole:
> I think it qualifies as a bug because it's somewhat unexpected. The
> question is: can we fix it without disrupting people who are
> accidentally depending on this behavior
> 
> Grr.
> 
> 
> David C.
> 

I submitted a bug report for this:
http://public.kitware.com/Bug/view.php?id=13187

regards,
Patrick
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] variable inheritance

2012-05-03 Thread Alexander Neundorf 
On Thursday 03 May 2012, David Cole wrote:
> I think it qualifies as a bug because it's somewhat unexpected. The
> question is: can we fix it without disrupting people who are
> accidentally depending on this behavior

The p-word again ?

Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Why does CMAKE_FIND_FRAMEWORK always default to FIRST ignoring command line definitions?

2012-05-03 Thread Rolf Eike Beer 
Am Mittwoch, 2. Mai 2012, 14:48:23 schrieb Charlie Sharpsteen:
> This is observed OS X 10.6.8, XCode 4.2.6 and 10.7.3, XCode 4.3 with CMake
> 2.8.8. Say I have the following CMakeLists.txt:
> 
> PROJECT(find_tst)
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
> 
> MESSAGE(STATUS "Value of CMAKE_FIND_FRAMEWORK: ${CMAKE_FIND_FRAMEWORK}")
> 
> 
> Why does CMAKE_FIND_FRAMEWORK end up with a value of FIRST even though I
> pass -DCMAKE_FIND_FRAMEWORK=LAST when configuring?
> 
> grendel:build sharpie$ cmake .. -DCMAKE_FIND_FRAMEWORK=LAST

Because those value is set in the Darwin platform file 
(Modules/Platform/Darwin.cmake) which is taken into account by the PROJECT() 
call. So this is just overridden.

Eike

signature.asc
Description: This is a digitally signed message part.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Using CMake with ifort compiler

2012-05-03 Thread Alain Leblanc 
The cmake documentation for add_subdirectory() states that the 
CMakeLists files in the subdirectories should contain their own 
project() command invocation. Your build file in the subdirectory does 
not contain one. I don't know that it will be automatically be seen by 
CMake as a fortran project because this is what the project in the top 
directory is.


Also I don't see the need for the two project files. I know this is what 
is done in the tutorial, but you could put everything in the project 
file from the top directory.


On 5/3/12 9:25 AM, Vivek Venugopal wrote:

Thanks Kelly.

But i still get this error:
CMake cannot determine linker language for target:helloworld

Thanks,
Vivek


--
Vivek Venugopal


On May 2, 2012, at 6:36 PM, "Thompson, Kelly G" > wrote:


My bad.  You need to tell CMake that this is a Fortran project.  Try 
this:


# CMakeLists.txt

cmake_minimum_required(VERSION 2.8.7)

*project(helloworldproject Fortran)*

add_subdirectory(src)

# src/CMakeLists.txt

cmake_minimum_required(VERSION 2.8.7)

file(GLOB helloworld_SOURCES *.f90)

add_executable(helloworld ${helloworld_SOURCES})

-kt

*From:*Vivek Venugopal [mailto:vivek@gmail.com]
*Sent:* Wednesday, May 02, 2012 11:45 AM
*To:* Thompson, Kelly G
*Subject:* Re: [CMake] Using CMake with ifort compiler

I see an error during generate:

CMake Error: CMake cannot determine linker language for target:helloworld

CMake Error: Cannot determine link language for target "helloworld"

--

Vivek Venugopal




On May 2, 2012, at 12:45 PM, "Thompson, Kelly G" > wrote:


Try this:

# CMakeLists.txt

cmake_minimum_required(VERSION 2.8.7)

*project(helloworldproject)*

add_subdirectory(src)

# src/CMakeLists.txt

cmake_minimum_required(VERSION 2.8.7)

file(GLOB helloworld_SOURCES *.f90)

add_executable(helloworld ${helloworld_SOURCES})

-kt

*From:*cmake-boun...@cmake.org 
[mailto:cmake-boun...@cmake.org]
 *On Behalf Of *Vivek
Venugopal
*Sent:* Wednesday, May 02, 2012 9:39 AM
*To:* cmake@cmake.org 
*Subject:* [CMake] Using CMake with ifort compiler


I am using CMake 2.8.7 on a Linux machine with Intel 11.0
compilers. I am trying to use CMake for the first time as I would
like to build this project on both Windows and Linux machines.

I though of using a simple approach first and used a standard
Hello World example: My src/HelloWorld.f90:

  


|!Test helloworld in Fortran using Cmake|

|program hello|

| print *, "Hello World!"|

|end program hello|

My main CMakeLists.txt:

  


|# States that CMake required version must be greater than 2.8.7|

|cmake_minimum_required(VERSION 2.8.7)|

|enable_language (Fortran)|

|project(helloworld Fortran)|

|add_subdirectory(src)|

|SET_TARGET_PROPERTIES(helloworld PROPERTIES LINKER_LANGUAGE FORTRAN)|

My src/CMakeLists.txt:

  


|cmake_minimum_required(VERSION 2.8.7)|

|  |

|# Include the directory itself as a path to include directories|

|set(CMAKE_INCLUDE_CURRENT_DIR ON)|

|  |

|# For a large number of source files you can create it in a simpler way|

|# using file() function:|

|file(GLOB helloworld_SOURCES *.f90)|

I still get an error which says CMAKE_FORTRAN_LINK_EXECUTABLE
variable missing. I looked at Abinader's CMake tutorial#1

,
but haven't had success so far.

any suggestions?? Thanks in advance !

?]????B??[??[OH???\?^?N?L?\??Y?[Z[N??][??\?X[ ?][?? 
?][???[??\?\?Y??][?o(?[?H?Y??\?[[???[?Y?[??HO??[?????????B??]??B??]??B??]??B?????][?O?B??]??B??]??B???O?B??[?B



--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] variable inheritance

2012-05-03 Thread David Cole 
I think it qualifies as a bug because it's somewhat unexpected. The
question is: can we fix it without disrupting people who are
accidentally depending on this behavior

Grr.


David C.


On Thu, May 3, 2012 at 7:01 AM, Patrick Spendrin  wrote:
> Hi,
>
> I just found something new for me, and wondered if this qualifies as a bug:
>
> argv-bug.cmake
> function(testfunc1)
>    message(STATUS "testfunc1: ${ARGV0} ${ARGV1} ${ARGV2}")
>    testfunc2("${ARGV0}")
> endfunction(testfunc1)
>
> function(testfunc2)
>    message(STATUS "testfunc2: ${ARGV0} ${ARGV1} ${ARGV2}")
> endfunction(testfunc2)
>
> testfunc1(para1 para2 para3)
>
> # output:
> # L:\>cmake -P C:\kde\kde-stable\tmp\cmake-argv-bug\argv-bug.cmake
> # -- testfunc1: para1 para2 para3
> # -- testfunc2: para1 para2 para3
>
> It is clear why this happens: since ARGV1 and ARGV2 are not used, they
> do not get overwritten and thus are available in testfunc2. Since ARGVx
> are special variables though, I would think this is a bug?
>
> (I tested 2.8.4, 2.8.7 and 2.8.8, and all versions show this behaviour.)
>
> regards,
> Patrick
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Using CMake with ifort compiler

2012-05-03 Thread Vivek Venugopal 
Thanks Kelly. 

But i still get this error:
CMake cannot determine linker language for target:helloworld

Thanks,
Vivek


--
Vivek Venugopal


On May 2, 2012, at 6:36 PM, "Thompson, Kelly G"  wrote:

> My bad.  You need to tell CMake that this is a Fortran project.  Try this:
>  
> # CMakeLists.txt
> cmake_minimum_required(VERSION 2.8.7)
> project(helloworldproject Fortran)
> add_subdirectory(src)
>  
> # src/CMakeLists.txt
> cmake_minimum_required(VERSION 2.8.7)
> file(GLOB helloworld_SOURCES *.f90)
> add_executable(helloworld ${helloworld_SOURCES})
>  
> -kt
>  
> From: Vivek Venugopal [mailto:vivek@gmail.com] 
> Sent: Wednesday, May 02, 2012 11:45 AM
> To: Thompson, Kelly G
> Subject: Re: [CMake] Using CMake with ifort compiler
>  
> I see an error during generate:
> CMake Error: CMake cannot determine linker language for target:helloworld
> CMake Error: Cannot determine link language for target "helloworld"
> 
> --
> Vivek Venugopal
> 
> 
> 
> On May 2, 2012, at 12:45 PM, "Thompson, Kelly G"  wrote:
> 
> Try this:
>  
> # CMakeLists.txt
> cmake_minimum_required(VERSION 2.8.7)
> project(helloworldproject)
> add_subdirectory(src)
>  
> # src/CMakeLists.txt
> cmake_minimum_required(VERSION 2.8.7)
> file(GLOB helloworld_SOURCES *.f90)
> add_executable(helloworld ${helloworld_SOURCES})
>  
> -kt
>  
> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of 
> Vivek Venugopal
> Sent: Wednesday, May 02, 2012 9:39 AM
> To: cmake@cmake.org
> Subject: [CMake] Using CMake with ifort compiler
>  
> 
> I am using CMake 2.8.7 on a Linux machine with Intel 11.0 compilers. I am 
> trying to use CMake for the first time as I would like to build this project 
> on both Windows and Linux machines.
> 
> I though of using a simple approach first and used a standard Hello World 
> example: My src/HelloWorld.f90:
> 
>  
> !Test helloworld in Fortran using Cmake
> program hello
> print *, "Hello World!"
> end program hello
> My main CMakeLists.txt:
> 
>  
> # States that CMake required version must be greater than 2.8.7
> cmake_minimum_required(VERSION 2.8.7)
> enable_language (Fortran)
> project(helloworld Fortran)
> add_subdirectory(src)
> SET_TARGET_PROPERTIES(helloworld PROPERTIES LINKER_LANGUAGE FORTRAN)
> My src/CMakeLists.txt:
> 
>  
> cmake_minimum_required(VERSION 2.8.7)
>  
> # Include the directory itself as a path to include directories
> set(CMAKE_INCLUDE_CURRENT_DIR ON)
>  
> # For a large number of source files you can create it in a simpler way
> # using file() function:
> file(GLOB helloworld_SOURCES *.f90)
> I still get an error which says CMAKE_FORTRAN_LINK_EXECUTABLE variable 
> missing. I looked at Abinader's CMake tutorial#1, but haven't had success so 
> far.
> any suggestions?? Thanks in advance !
> 
> �]�ܙ��B��[��[OH��۝\�^�N�L�\ٛ۝Y�[Z[N��][��\�X[�][��  
> �][���[��\�\�Y��][�ȏ�[�H�Y��\�[ۜ���[���[�Y�[��HO��[��Μ��Μ���B��]��B��]��B��]��B�؛���][�O�B��]��B��]��B�؛�O�B��[�B
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Running Python unit tests importing modules built in CMake

2012-05-03 Thread Bradley Lowekamp 
Hello,

For testing python another alternative is to create a python virtual 
environment and install you python package into that. Here is an example of how 
I have done that:

https://github.com/SimpleITK/SimpleITK/blob/master/Wrapping/CMakeLists.txt#L97

Brad

On May 2, 2012, at 9:26 PM, David Cole wrote:

> Are you using "add_test" to add the tests in the CMakeLists file?
> 
> If so, you can set the test ENVIRONMENT property to set PYTHONPATH
> when ctest executes the test. See property doc here:
> 
>  http://cmake.org/cmake/help/v2.8.8/cmake.html#prop_test:ENVIRONMENT
> 
> 
> On Wed, May 2, 2012 at 5:17 PM, Lori A. Pritchett-Sheats
>  wrote:
>> I'm building Python modules using SWIG and CMake, and have run into a
>> problem running Python unit tests for these built modules. I can not find a
>> slick way to set the Python module search path when running the test. The
>> usual trick of setting sys.path in the scripts will not work here because I
>> don't know the location of the build directory. I've tried updating
>> PYTHONPATH in my CMakeList.txt file but that change isn't picked up when the
>> test is executed. I could create the unit test modules at build time using
>> CONFIGURE_FILE replacing @CMAKE_CURRENT_BINARY_DIR@ in a sys.path line, but
>> that seems heavy-handed. Has anyone else run into this problem and found
>> better a solution?
>> 
>> --
>> Lori A. Pritchett-Sheats, PhD.
>> CCS-2, Computational Physics and Methods
>> Office: 505-665-6675
>> Fax: 505-665-4972
>> 
>> Los Alamos National Laboratory
>> P.O. Box 1663
>> MS D413
>> Los Alamos, NM 87544
>> 
>> --
>> 
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
> --
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake


Bradley Lowekamp  
Medical Science and Computing for
Office of High Performance Computing and Communications
National Library of Medicine 
blowek...@mail.nih.gov



--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] variable inheritance

2012-05-03 Thread Patrick Spendrin 
Hi,

I just found something new for me, and wondered if this qualifies as a bug:

argv-bug.cmake
function(testfunc1)
message(STATUS "testfunc1: ${ARGV0} ${ARGV1} ${ARGV2}")
testfunc2("${ARGV0}")
endfunction(testfunc1)

function(testfunc2)
message(STATUS "testfunc2: ${ARGV0} ${ARGV1} ${ARGV2}")
endfunction(testfunc2)

testfunc1(para1 para2 para3)

# output:
# L:\>cmake -P C:\kde\kde-stable\tmp\cmake-argv-bug\argv-bug.cmake
# -- testfunc1: para1 para2 para3
# -- testfunc2: para1 para2 para3

It is clear why this happens: since ARGV1 and ARGV2 are not used, they
do not get overwritten and thus are available in testfunc2. Since ARGVx
are special variables though, I would think this is a bug?

(I tested 2.8.4, 2.8.7 and 2.8.8, and all versions show this behaviour.)

regards,
Patrick
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Dependencies between independent projects

2012-05-03 Thread Alexander Broekhuis 
Hi André,

2012/5/2 André Caron 
>
> I've come up with a simple workflow where each library project exports a
> "library-config.cmake" file and any project that includes it defines the
> "library_DIR" variable to the folder containing this "library-config.cmake"
> file so that it can be resolved from anywhere in the CMake scripts using
> only "find_package()".  This way, when the library can either set the
> "library_DIR" variable or inherit it from the parent project.  This solves
> the problem of using either its own Git submodule or a parent project's Git
> submodule, ensuring you build the library only once for the entire project
> and that all sub-projects use the same version.
>

I am testing with a similar solution, having an example is great! I like
the solution on how to build the dependencies (using the add_subdirectory
in the config.cmake). I might need to reorder my project a little bit for
this, but definitely looks useful!


> I'm slowly converting all my projects to CMake using this pattern.  You
> can find some of those on my GitHub profile[2].  One example is cfcgi[3].
>  Note that I'm learning a lot along the way and I don't guarantee that all
> of this conforms to CMake best practices.  I'm only referring to this for
> the project structure and CMake concept to clarify my explanation with an
> example.  That being said, if anyone has comments about the CMake scripts
> in there, your input is welcome :-)
>

I'll see if I can make an example for my usecase. If I have some
comments/additions I will post them here.


-- 
Met vriendelijke groet,

Alexander Broekhuis
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMake not parsing quotes properly for VS compiler flags.

2012-05-03 Thread Luke Snape 
Hello,

I am adding some custom compiler options to a VS2008 project containing paths 
with spaces. As such, I require double quotes around the argument name to 
ensure the spaces in the path are not interpreted as individual compiler flags. 
e.g:

set (CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} 
/MyCustomTool:\"$(SolutionDir)\")

The quotes are being removed from the argument. If you put 
\\\"$(SolutionDir)\\\" then you get MyCustomTool:\"$(SolutionDir)". Better, but 
still won't compile correctly!

If anyone knows how I can work around this issue I would be very grateful!

Many Thanks,

Luke 
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake