Re: [CMake] CMake 2.8.6-rc2 ready for testing!

Hello, http://www.cmake.org/Bug/view.php?id=12260 is listed with target 2.8.6, but it's not listed in the changes (yet?). Will it be fixed for the next release or will it be pushed to 2.8.7? Regards Johannes ___ Powered by www.kitware.com Visit

Re: [CMake] CMake 2.8.6-rc2 ready for testing!

Hello Dave, Am 05.09.2011 18:29, schrieb Johannes Stallkamp: http://www.cmake.org/Bug/view.php?id=12260 is listed with target 2.8.6, but it's not listed in the changes (yet?). Will it be fixed for the next release or will it be pushed to 2.8.7? Thank you, for fixing this. I will try

Re: [CMake] Bug fix requests for the *next* release of CMake...

Probably a bit late, but I was on vacaction: http://www.cmake.org/Bug/view.php?id=12260 Johannes ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep

Re: [CMake] CMake 2.8.5-rc1 ready for testing!

Hi, Would be great if http://www.cmake.org/Bug/view.php?id=12260 would make it into 2.8.5. Best Johannes ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep

[CMake] CTest incorrectly parses valgrind output

Hi, I just noticed that CTest 2.8.4 incorrectly parses valgrind's memcheck output because it does not always take into account that numbers reported by valgrind can be larger than 1,000 and then will contain a comma as thousand-delimiter. Therefore, many errors/potential errors are not correctly

Re: [CMake] CTest incorrectly parses valgrind output

Hi, Am 09.06.2011 13:20, schrieb Michael Wild: On 06/09/2011 01:11 PM, Rolf Eike Beer wrote: Hi, I just notied that CTest 2.8.4 incorrectly parses valgrind's memcheck output because it does not always take into account that numbers reported by valgrind can be larger than 1,000 and then will

Re: [CMake] CTest incorrectly parses valgrind output

Hi, Yes. And please use unified diff format. Preferred is if you could do a checkout of CMake git and commit your patch (locally) and then do git format-patch HEAD^ and attach the resulting 0001-* file to the bug. Just did so. Hope the patch format is correct. Please advise, if not.

Re: [CMake] Building a Version Header

Hi, Am 08.07.2010 22:31, schrieb Tyler Roscoe: On Wed, Jul 07, 2010 at 10:43:15PM -0400, John Drescher wrote: On Wed, Jul 7, 2010 at 9:44 PM, Clark Gaebel cg.wowus...@gmail.com wrote: I would like to generate file that looks something like this: // version.h #define VERSION

Re: [CMake] Building a Version Header

Am 09.07.2010 12:56, schrieb Michael Hertling: As the version target is always out of date it will be build each time you (re)build main, but since CONFIGURE_FILE() obviously does not touch the output file as long as it won't change, version.h isn't timestamped, so it doesn't trigger the

Re: [CMake] CMake cross-compilation best practices

Hello Romain, Romain CHANU schrieb: If I need to compile a library on both Linux and Windows, the best CMake practice would be to write toolchain files for Linux and Windows (cf. http://www.cmake.org/Wiki/CMake_Cross_Compiling) Is that correct? Do you really want to cross-compile (i.e. build

[CMake] OpenMP compiler flag questoin

Hello, if I use FIND_PACKAGE( OpenMP ) I get the variables OpenMP_C_FLAGS and OpenMP_CXX_FLAGS correctly set to /openmp for VC2005. Is it correct behaviour that these are not automatically added to the CMAKE_CXX_FLAGS_[RELEASE|DEBUG] variables (and thus, the option is not configured in VC's

[CMake] CTest coverage test and external subdirs

Hello, I am still trying to get ctest working on our directory structure. Thanks to the bugfix in 2.8, running the test itself works fine. However, there seems to be an issue with code coverage testing. Assuming the following directory structure: projects/ libFoo/ cmake

[CMake] CTest: another sub-directory issue / coverage test

Hello, I am still experimenting and learning how to setup CTest/CDash support for our projects. We have the following directory structure for our projects: Foo/ cmake CMakeLists.txt CTestConfig.cmake include Foo.h src Foo.cpp FooTest.cpp Running

Re: [CMake] CTest: another sub-directory issue / coverage test

Richard, Richard Wackerbarth schrieb: Johannes, Is there any compelling reason to place the cmake control files in a directory under the root? Foo/ CMakeLists.txt CTestConfig.cmake include Foo.h src Foo.cpp FooTest.cpp is a more conventional structure

[CMake] Problem with CTest SUBDIRS

Hello, sorry for asking this right after the release of CMake 2.8, but I only stumpled upon the problem right now (using 2.6, however). Are there any plans to fix http://public.kitware.com/Bug/view.php?id=9090 (still marked as open)? We actually do have the same situation that we add

Re: [CMake] Problem with CTest SUBDIRS

Tyler Roscoe schrieb: On Mon, Nov 09, 2009 at 07:18:05PM +0100, Johannes Stallkamp wrote: Are there any reasons the suggested patch in http://public.kitware.com/Bug/view.php?id=9090 is not integrated into current CMake version? Looks like Zach Mullen just applied the patch

[CMake] CPack + NSIS: Are empty components omitted?

Hello, I have another problem with CPack and NSIS package generator: I currently create a CMake component for each sub-project/component of my software. The sub-project CMakeLists.txt use cpack_add_component(...) to define display name, description and especially dependencies. Now, appA might

[CMake] CPack + NSIS: Dependencies between components

Hello, I have a question concerning component-based install with CPack and NSIS: Among others, I have a library libA and a component depending on that library, appA. Using CPACK_COMPONENT_APPA_DEPENDS I can achieve that libA is installed if I select appA. But: If appA is the only component