Re: [CMake] using source files in build directory

Hi, For header files, that's quite a normal thing to do - you just need to add the CMAKE_CURRENT_BINARY_DIR to your include directories. For .cpp files, you can write your target so that it is referencing the source file in the binary directory. I.e.: configure_file(

Re: [cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU

On 23.10.2015 16:52, Brad King wrote: Thanks. Fixed: CTest: Fix regression in handling of a RUN_SERIAL test that fails https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e61973e1 I've queued this for merge to 'release' for 3.4.0-rc3. -Brad Thanks! Nils -- Powered by www.kitware.com

Re: [CMake] Finding debug Qt libraries without CMAKE_BUILD_TYPE set to None

Here is what I tried for Qt4 (that is what I am using), using cmake 3.3.2 on Windows 7 find_package(Qt4 4.8.5 REQUIRED QtCore QtGui QtXml Qt3Support QtWebKit QtSql QtSvg QtNetwork QAxContainer) set_target_properties(Qt4::QtCore PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG")

Re: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

On 10/07/2015 12:45 PM, Orion Poplawski wrote: > There also appears to be a similar issue with building Paraview where the > MPI_INLCUDE_PATH is no longer being passed to the compile line. Can you provide any more detail on this problem? There was only one change to FindMPI between 3.3.2 and

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc2-903-g786a5bb

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, next has been updated via 786a5bbd1612a6da3487aae97ae99a88f20ea272 (commit) via

Re: [CMake] Finding debug Qt libraries without CMAKE_BUILD_TYPE set to None

That was it, I had to replace MAP_IMPORTED_CONFIG_COVERAGE with MAP_IMPORTED_CONFIG_NONE as I have set(CMAKE_BUILD_TYPE NONE) I hope this is useful to others. On Fri, Oct 23, 2015 at 9:38 AM, Tom Kacvinsky wrote: > Here is what I tried for Qt4 (that

Re: [cmake-developers] CMake 3.4.0-rc2 cpack xz compressed debian packages broken

Le 23/10/15 11:22, Nils Gladitz a écrit : Given this test case: cmake_minimum_required(VERSION 3.3) project(Foo NONE) install(FILES CMakeLists.txt DESTINATION tmp) set(CPACK_DEBIAN_COMPRESSION_TYPE "xz") set(CPACK_PACKAGE_CONTACT "f...@bar.com") include(CPack) A debian

[cmake-developers] CMake 3.4.0-rc2 cpack xz compressed debian packages broken

Given this test case: cmake_minimum_required(VERSION 3.3) project(Foo NONE) install(FILES CMakeLists.txt DESTINATION tmp) set(CPACK_DEBIAN_COMPRESSION_TYPE "xz") set(CPACK_PACKAGE_CONTACT "f...@bar.com") include(CPack) A debian package created with: cpack -G DEB Fails during

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc2-921-g88b9b0a

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, next has been updated via 88b9b0a6f138fa933cd9d286c02fe5a7e255080a (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc2-923-g8fbc8e4

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, next has been updated via 8fbc8e473b347d69331cd120aea3dd6c33e98599 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.4.0-rc2-317-g66fcb15

_VERSION_MINOR 4) -set(CMake_VERSION_PATCH 20151023) +set(CMake_VERSION_PATCH 20151024) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] using source files in build directory

That's really more of a job for source control if you add like if( exists ) for each potential file you want to experiment with it could be done. On Fri, Oct 23, 2015 at 2:07 AM, Johannes Zarl-Zierl wrote: > Hi, > > For header files, that's quite a normal thing

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc2-925-gaddb1da

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, next has been updated via addb1dad4f1f99e054f3fc3e0f94d571ef8842c8 (commit) via

Re: [CMake] add_dependencies being ignored for add_custom_command?

The command "add_dependencies" [0] only works on targets. See the CMake Tutorial for how to generate files as part of the build that later targets rely on. [1]. [0] https://cmake.org/cmake/help/v2.8.12/cmake.html#command:add_dependencies [1] https://cmake.org/cmake-tutorial/#s5 On Fri, Oct 23,

Re: [cmake-developers] CMake 3.4.0-rc2 cpack xz compressed debian packages broken

On 10/23/2015 06:04 AM, Raffi Enficiaud wrote: > Fix attached! (based on current master a03c13a) Thanks. I backported it to 'release' and applied: CPackDEB: Use proper compression scheme for control.tar.gz https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66178ae5 > PS.: I will add the

Re: [cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU

On 10/23/2015 03:23 AM, Nils Gladitz wrote: > I reduced it to this test case: > >cmake_minimum_required(VERSION 3.4) > >project(Foo NONE) > >enable_testing() > >add_test(NAME foo COMMAND command_not_found) >set_property(TEST foo PROPERTY RUN_SERIAL ON) > >add_test(NAME

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc2-905-g9a24d6a

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, next has been updated via 9a24d6a269df453ce684bfe856b7a3570f5b141f (commit) via

[cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU

I switched from 3.2.1 to 3.4.0-rc2 on a Windows and a Linux dashboard client for a custom project. On the Linux client parallel testing now loops with 100% CPU somewhere in cmCTestMultiProcessHandler::StartNextTests and cmCTestMultiProcessHandler::CheckOutput. I don't have a proper stack

Re: [cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU

On 10/23/2015 09:10 AM, Nils Gladitz wrote: I switched from 3.2.1 to 3.4.0-rc2 on a Windows and a Linux dashboard client for a custom project. On the Linux client parallel testing now loops with 100% CPU somewhere in cmCTestMultiProcessHandler::StartNextTests and

[CMake] add_dependencies being ignored for add_custom_command?

Hey, I'm at a loss here: I have a command that's run with add_custom_command(). I need to run it before compiling a library that I add with add_library(), because it generates some header files. This was my first try: file1: {{{ add_custom_command( OUTPUT foo.hpp COMMAND bar ) }}}

Re: [cmake-developers] Patch: install universal iOS libraries

On 08/10/15 02:37, Ruslan Baratov wrote: >>> export CORRESPONDING_DEVICE_PLATFORM_NAME=iphoneos >>> export CORRESPONDING_DEVICE_SDK_NAME=iphoneos9.0 >>> export SDK_NAME=iphonesimulator9.0 >> Could you use those variables to avoid hardcoding iphoneos/simulator in >> the module? > I see

[CMake] Obtaining build time stamps

Is there a way of tracking the time individual compiles take using cmake? What I am after is a cmake variable to set, or a cmake invocation option that will in the end generate Makefiles that output the time it takes for each compile/link. I am trying to track down a build performance issue and