Re: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

Here's the sample code: https://github.com/NickNick/cmake-interface-includes/commits/master . The second commit breaks the build. I sort of understand why it does, but that means I can't use the INTERFACE-trick, so to say, even with static libraries. Thanks for linking the other bug. On Mon,

Re: [cmake-developers] CPack IFW generator

On 07/29/2014 01:47 PM, Konstantin Podsvirov wrote: I have some news and changes. The source code is now available here: http://git.podsvirov.pro/?p=kitware/cmake.git New changes applied here: CPackIFW: Document cpack_ifw_configure_component DEPENDS option

Re: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree

On 07/28/2014 11:07 AM, Daniele E. Domenichelli wrote: I applied the changes you requested to the documentation, rebased, and merged to next for testing. Thanks. While reviewing the commits in 'next' again I realized that assuming paths are relative to CMAKE_BINARY_DIR may not be correct.

[cmake-developers] [CMake 0015046]: visual studio configuration sometimes switches from x64 to win32

The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15046 == Reported By:tim blechmann Assigned To:

Re: [cmake-developers] LZMA support

On 07/23/2014 10:43 AM, Brad King wrote: I've merged the topic to 'next' for testing, but without the CPack or ExternalProject pieces. Likely some more portability fixes will be required after testing on the dashboard. Once that is clean I will add the other changes again on top of the

Re: [cmake-developers] CPack IFW generator

Hi guys! 30.07.2014, 17:15, Brad King brad.k...@kitware.com: New changes applied here: CPackIFW: Document cpack_ifw_configure_component DEPENDS option http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2340001 CPackIFW: Add package configuration variables

Re: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

On 07/30/2014 05:31 AM, Nick Overdijk wrote: https://github.com/NickNick/cmake-interface-includes/commits/master Thanks. For reference, the summary is: cmake_minimum_required(VERSION 2.8.12) project(FOO CXX) add_library(foo foo/foo.cpp) target_include_directories(foo INTERFACE foo)

Re: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could.

True, I was just bothered by it when we got distcc running with a good amount of cores. Thanks for your effort. :) I'll try and make something with the things I've learned (I'm thinking of making some functions that propagate usage requirements yet link with INTERFACE or something along those

[cmake-developers] adding command line flags for CMAKE_MAKE_PROGRAM

I was trying to get ExternalProjects generated with the Ninja generator to do a better job of handling multiple CPUs and load, so I tried the naïve solution below. I needed to add flags to the program named in CMAKE_MAKE_PROGRAM. This is difficult because CMAKE_MAKE_PROGRAM is a string; I can

Re: [cmake-developers] ExternalProject: adding command line flags for CMAKE_MAKE_PROGRAM

On 07/30/2014 11:06 AM, Williams, Norman K wrote: I was trying to get ExternalProjects generated with the Ninja generator to do a better job of handling multiple CPUs and load, so I tried the naïve solution below. For reference in the archives, your previous post about this was here: CMake,

Re: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree

Hello Brad, On 30/07/14 15:32, Brad King wrote: Thanks. While reviewing the commits in 'next' again I realized that assuming paths are relative to CMAKE_BINARY_DIR may not be correct. Some projects may be nested inside others, and the CMAKE_BINARY_DIR may not be the proper location for a

Re: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree

On 07/30/2014 11:57 AM, Daniele E. Domenichelli wrote: I never used multiple project calls, so I don't know how it works, would PROJECT_BINARY_DIR be an appropriate replacement for CMAKE_BINARY_DIR? No, because we don't know if the most-nested project() call is the right one either. Should

[cmake-developers] [CMake 0015047]: BundleUtilities' fixup_bundle does not check to see if two libs are the same up to symlinks

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15047 == Reported By:Jordi Gutiérrez Hermoso Assigned

[cmake-developers] [CMake 0015048]: Semicolon in AIX compiler warning FAIL_REFEX causes it to match other output

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15048 == Reported By:Erik Lindahl Assigned To:

Re: [cmake-developers] LZMA support

2014-07-30 15:58 GMT+02:00 Brad King brad.k...@kitware.com: On 07/23/2014 10:43 AM, Brad King wrote: I've merged the topic to 'next' for testing, but without the CPack or ExternalProject pieces. Likely some more portability fixes will be required after testing on the dashboard. Once that

Re: [cmake-developers] LZMA support

On 07/30/2014 03:42 PM, Daniel Pfeifer wrote: I think we should add packaging options like 'CPACK_BINARY_7Z' to 'Modules/CPack.cmake'. Thanks. Patch applied: CPack: Add lzma-compressed package options http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d93e099 Maybe the options should be

[cmake-developers] [CMake 0015049]: Add detection for Fujitsu compilers

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15049 == Reported By:Erik Lindahl Assigned To:

[cmake-developers] scan-build of CMake

I am working on scan-build integration with ctest/CDash and did a build of CMake. The results show up in the warning section of the build: http://open.cdash.org/viewBuildError.php?type=1buildid=3429991 I excluded a few things in STL, but the rest of this might be worth looking at if anyone