[CMake] [PATCH] FindRuby.cmake does not support version 1.9.1

2009-12-28 Thread Guilherme Balena Versiani
Hello all, FindRuby.cmake from CMake 2.8.0 does not support Ruby 1.9.1, and has some errors on variable RUBY_NODOT_VERSION (it wasn't created resulting in _nothing_ in expansions). It follows attached a patch to be applied to solve these BUGs. Best regards, -- Guilherme Balena Versiani FindRub

Re: [CMake] Coverage Tests

2009-12-28 Thread Daniel Stonier
2009/12/29 Bill Hoffman > Daniel Stonier wrote: > >> Had a problem with coverage tests on gentoo today. >> >> Cmake 2.6.4-r3, g++ 4.3.2-r3, ccache 2.4-r7. >> It couldn't find the coverage files, even with cflags and link flags >> enabling "-fprofile-arcs -ftest-coverage". Similar worked on ubuntu

Re: [CMake] Coverage Tests

2009-12-28 Thread Bill Hoffman
Daniel Stonier wrote: Had a problem with coverage tests on gentoo today. Cmake 2.6.4-r3, g++ 4.3.2-r3, ccache 2.4-r7. It couldn't find the coverage files, even with cflags and link flags enabling "-fprofile-arcs -ftest-coverage". Similar worked on ubuntu no problem. A workaround for it I f

Re: [CMake] target_link_libraries: prefer static to dynamic

2009-12-28 Thread Bill Hoffman
Pau Garcia i Quiles wrote: I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to happen automagically. That was the whole point of this thread :-) OK, well the thread has a very bad subject then It should be "force find_library to choose static over shared". This really ha

Re: [CMake] target_link_libraries: prefer static to dynamic

2009-12-28 Thread Michael Wild
On 28. Dec, 2009, at 12:40 , Pau Garcia i Quiles wrote: >> That sounds doable to me. However, you'd need a mechanism to express the >> same preference when calling find_package and then have find_package >> communicate that to find_library. Not sure how fine-grained >> the control should be for

[CMake] Coverage Tests

2009-12-28 Thread Daniel Stonier
Had a problem with coverage tests on gentoo today. Cmake 2.6.4-r3, g++ 4.3.2-r3, ccache 2.4-r7. It couldn't find the coverage files, even with cflags and link flags enabling "-fprofile-arcs -ftest-coverage". Similar worked on ubuntu no problem. A workaround for it I found was to explicitly link

[CMake] Coverage - no more lines in the file

2009-12-28 Thread Daniel Stonier
I get an odd error from ctest coverages. "Looks like there are more lines in the file:" Not really sure where to look to fix this one - not getting much from google. Regards, Daniel. -- Phone : +82-10-5400-3296 (010-5400-3296) HomePage: http://snorriheim.dnsdojo.com/ Yujin Robot: http://www.yu

Re: [CMake] target_link_libraries: prefer static to dynamic

2009-12-28 Thread Pau Garcia i Quiles
> That sounds doable to me. However, you'd need a mechanism to express the same > preference when calling find_package and then have find_package communicate > that to find_library. Not sure how fine-grained > the control should be for FindXXX.cmake modules that find more than one > library (or

Re: [CMake] target_link_libraries: prefer static to dynamic

2009-12-28 Thread Pau Garcia i Quiles
>> What version of CMake are you using?  This should work...  As of 2.6.2 (I >> think...) CMake uses full paths to libraries, see policy CMP0003: >> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#policy:CMP0003.  It does >> not matter if there are two libraries in the same directory.  There

Re: [CMake] target_link_libraries: prefer static to dynamic

2009-12-28 Thread Michael Wild
On 27. Dec, 2009, at 23:30 , Pau Garcia i Quiles wrote: > On Sun, Dec 27, 2009 at 10:16 PM, Michael Wild wrote: >> >> On 27. Dec, 2009, at 20:41 , Pau Garcia i Quiles wrote: >> >>> On Sun, Dec 27, 2009 at 10:59 AM, Michael Wild wrote: On 26. Dec, 2009, at 17:53 , Pau Garcia i Quile

Re: [CMake] target_link_libraries: prefer static to dynamic

2009-12-28 Thread Michael Wild
On 28. Dec, 2009, at 5:38 , Bill Hoffman wrote: > Pau Garcia i Quiles wrote: >> On Sun, Dec 27, 2009 at 6:26 PM, Bill Hoffman >> wrote: >>> Pau Garcia i Quiles wrote: Hello, I think this has already been discussed and the answer is negative but still: when I do target_link_