Re: [CMake] [EXTERNAL] Re: Get ctest -S script to pull from git branch other than 'master'?

Xavier, Thanks for the info. I got another email from Brad King and he also pointed out the same thing: https://cmake.org/cmake/help/v3.6/command/ctest_start.html#command:ctest_start and then Brad updated the documentation for ctest_update() to state that it will just keep you on

Re: [CMake] How do you handle recursive dependencies in CMake

If the projects are each providing their own Config.cmake file then you probably will want to use those instead of Find modules. Instead of using the Foo_Bar_LIBRARIES variable though, try using the actual imported targets from the config files. Those should have the appropriate dependency

Re: [CMake] Get ctest -S script to pull from git branch other than 'master'?

Hi Ross, Here is how I do it in my case: ... # Initial checkout if no source directory if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}") message("Initial checkout...") set(CTEST_CHECKOUT_COMMAND "git clone --branch ${GIT_BRANCH} ${REPOSITORY} ${SOURCE_DIR_NAME}") endif() # Initialize testing

Re: [CMake] How do you handle recursive dependencies in CMake

In my case all projects provide their own FooBarConfig.cmake, but not a FindFooBar.cmake. For this reason I wanted to use those, because I thought it saves me the effort of writing a lot of FindFooBar.cmake files, and it also seemed like the right way to do it, because it provides things like

[CMake] CPack and executable permissions on linux

Hey guys, I am creating a RPM package with CMake. Here is a small example of how it looks: cmake_minimum_required(VERSION 3.5) set(BOOST_LIB "${CMAKE_CURRENT_SOURCE_DIR}/boost") file(GLOB_RECURSE BOOST_LIBRARIES ${BOOST_LIB}/*) install(FILES

[CMake] Off-topic? Winmm linking/running problems

I have a multiplatform viewer and recently I started to experience some very weird behavior. I am using the latest cmake 3.5.3 rc1 and the latest released ninja (1.7), albeit the problem appears with NMake Makefiles too. The viewer links against winmm.dll, the windows multimedia library for

Re: [CMake] [EXTERNAL] Re: Get ctest -S script to pull from git branch other than 'master'?

On 6/8/2016 12:59 PM, Bartlett, Roscoe A wrote: Xavier, Thanks for the info. I got another email from Brad King and he also pointed out the same thing: https://cmake.org/cmake/help/v3.6/command/ctest_start.html#command:ctest_start and then Brad updated the documentation for

Re: [CMake] CPack and executable permissions on linux

On 08/06/16 17:58, Kristian wrote: > Hey guys, > > I am creating a RPM package with CMake. Here is a small example of how > it looks: > > > > cmake_minimum_required(VERSION 3.5) > > set(BOOST_LIB "${CMAKE_CURRENT_SOURCE_DIR}/boost") > > file(GLOB_RECURSE BOOST_LIBRARIES ${BOOST_LIB}/*) >

[CMake] Fwd: CPack and executable permissions on linux

> Before running this cmake script, I am setting executable permissions on the > build machine, where the package is created. With install(FILES ...) command permissions set to source file will be ignored by default (this is missing from documentation). You could set permissions with PERMISSIONS

[CMake] detect Nightly test run

Hi folks, I am wondering if it is possible to detect in CMakeLists.txt whether a Nightly target is being configured? What I am trying to do, is to set extra parameters (--gtest_repeat=200) on some tests; but because this slows things down, I'd like to have this only in the Nightly run. Any

Re: [CMake] CPack and executable permissions on linux

> This could probably be supported by adding USE_SOURCE_PERMISSIONS for > install(FILES ...) would you be willing to contribute a patch? Misses that this is not cmake-dev mailing list... Patch would still be appreciated but you could also file a feature request (for extending the documentation

[CMake] CMake v3.6.0 rc1

I tried v3.6.0 rc1 but it fails on linking with a message about unknown symbols when doing cmake -E vs_link_dll on a windows library. It seems not to recognize the symbols in, for example, tinyxml2. The same code works just fine under cmake v3.5.2. -- Powered by www.kitware.com Please keep

Re: [CMake] Off-topic? Winmm linking/running problems

On 08/06/2016 12:11 p.m., Gonzalo Garramuño wrote: I have a multiplatform viewer and recently I started to experience some very weird behavior. Found the problem being the volume control not being 32bits. Sorry for the noise. -- Powered by www.kitware.com Please keep messages on-topic and

Re: [CMake] How do you handle recursive dependencies in CMake

The FooBarConfig.cmake is something that should be generated by FooBar's build. The reason you don't get absolute paths for the "libraries" from a package config file is that they're not actually libraries but imported targets. The imported target let's you treat "foo" as though it were a

[CMake] AUTORCC recompiles unchanged rcc files every build using ninja

Hi, In cmake 3.5.0, 3.5.2 and 3.6.0, my resource file is compiled every time I build, even when they are not changed. | cmake_minimum_required(VERSION 3.2)| |project(auto_moc_uic_rcc)set(CMAKE_INCLUDE_CURRENT_DIR ON)set(CMAKE_AUTOMOC ON)set(CMAKE_AUTOUIC ON)set(CMAKE_AUTORCC ON)find_package

Re: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE

2016-06-08 9:45 GMT+02:00 Domen Vrankar : > > I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6 > > (default cmake from repo was 2.8.12?) but it seems when making a package > > the arch is set incorrectly to x86_64 instead of ppc64le. > > I don't

Re: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE

> I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6 > (default cmake from repo was 2.8.12?) but it seems when making a package > the arch is set incorrectly to x86_64 instead of ppc64le. I don't have access to a ppc with Linux but it seems that 'uname -m' (default that is

Re: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE

> The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by cmake > --system-information) uses the same "uname -m" > see Modules/CMakeDetermineSystem.cmake. > > So there is something odd to have one right and the other wrong... In that case it's quite possible that

Re: [CMake] Problem building CMake with system OPENSSL

Thanks you for the fix and tips! Brad From: Brad King [brad.k...@kitware.com] Sent: Tuesday, June 07, 2016 3:13 PM To: Lowekamp, Bradley (NIH/NLM/LHC) [C] Cc: CMake@cmake.org Subject: Re: [CMake] Problem building CMake with system OPENSSL On 06/07/2016

[CMake] How about Windows SDK support in cmake?

Hi, Since cmake can generate MSBuild build file, why could cmake support building with Windows SDK? I searched the internet, and only found a few posts talking about this, and there's a repo on Github which named FindWindowsSDK. Do we have any inside news from the core developers? Thanks,

Re: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE

Domen Vrankar writes: > > > The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by cmake > > --system-information) uses the same "uname -m" > > see Modules/CMakeDetermineSystem.cmake. > > > > So there is something odd to have one right and the other wrong... > >

Re: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE

I was able to verify, btw, that Fedora 19 + Power8 outputs ppc64le for uname -m so I assume it works correctly on EL7 as well. Testead via an IBM machine hosted at the OSU Open Source Lab that we can access and use for testing. - Chuck On Wed, Jun 8, 2016 at 10:33 AM, M Kelly

Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

Hi, the code looks right to me. Thanks a lot for fixing that so quickly. Brad is also right about the first byte. The command has the argument already attached. Michael On 06/08/2016 06:46 PM, Brad King wrote: > On 06/08/2016 12:43 PM, Rolf Eike Beer wrote: >>> Run ranlib on archives only if

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-54-g5572f5f

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, master has been updated via 5572f5fffd040473c588215a7c87a12530e1548e (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-56-g8632251

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, master has been updated via 8632251b25c217e12ae8741e935d6b9aa03ac04b (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-65-gc3ba3a4

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-125-g7160c8c

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 7160c8c8dea75dda8f016823ed0a0ff2e922fdef (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-137-g6c7dd8e

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 6c7dd8eb8ae00a1a0b8c628e4d6e3c7b5f3ea1f9 (commit) via

Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

On 06/08/2016 12:43 PM, Rolf Eike Beer wrote: >> Run ranlib on archives only if the tool is available >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671 > > Shouldn't the first check also be "cmd == ":" instead of only > checking the first byte? No, because the command in question

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-129-g5780391

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 5780391f96f58561e08ed115d1fd8a0c4e9695d8 (commit) via

Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

On 06/08/2016 03:33 AM, "Michael Jäntsch" wrote: > the : is obviously the default for noop which is correct for > Linux but not for Windows. My CMakeCache has the following entry: > //noop for ranlib > CMAKE_RANLIB:INTERNAL=: I see that here:

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-127-g0b5f585

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 0b5f5857d3cbf5ce77c78fcaef36c4cd001cd4f0 (commit) via

Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

Am Mittwoch, 8. Juni 2016, 12:24:29 schrieb Brad King: > On 06/08/2016 03:33 AM, "Michael Jäntsch" wrote: > > the : is obviously the default for noop which is correct for > > Linux but not for Windows. My CMakeCache has the following entry: > > //noop for ranlib > > > CMAKE_RANLIB:INTERNAL=: > I

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-58-g5a13dc0

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, master has been updated via 5a13dc0b6e462745e12946e209b815131ea47f25 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-63-gfb8b8dd

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-61-g5804068

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, master has been updated via 5804068c220e2f9870dbcb24ee68eb610c9b4ff4 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-67-gba92e11

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-123-g9a4fa80

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 9a4fa800379b26bfbae3a9a98ed94baf58166713 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-139-g6455c5c

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 6455c5c0afeba7e9f7f5ecc8f04b25f1462157f8 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-141-g19eb5fe

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 19eb5feb9d2e7e3b33b3402b1e5fb0c80560e647 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-143-g7e7dd8b

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 7e7dd8ba118242cb86a944d130b91f7464028499 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-151-gbcce79e

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 bcce79e9b7de4ae5fba7e7a1139586ccdf5c77e3 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-153-g7c99e0f

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 7c99e0fa021fcade3968d3ab75fb0bff5b04d809 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-116-gcdc2c6a

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 cdc2c6a7a48b66f043a832d0417a1475b53cb63f (commit) via

[cmake-developers] cmLocalGenerator::GetTargetFlags

Hi everybody, what use is the "flags" out-parameter in cmLocalGenerator::GetTargetFlags? It is only ever set for targets of type EXECUTABLE and is filled based on the *linker language* of the target. I really do not see any use for this information, and indeed the flag seems unused in the cmake

Re: [cmake-developers] CMake daemon-mode

On 06/07/2016 11:42 AM, Daniel Pfeifer wrote: > On Mon, Jun 6, 2016 at 7:24 PM, Brad King wrote: >> On 06/06/2016 11:39 AM, Tobias Hunger wrote: >> >>> A big chunk of Stephen's work has not even landed in my branch yet. Since >>> cmake >>> reformated all the source in the

Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

Ah ok. That is interesting. If I set the CMAKE_RANLIB (after my Project command) it gets executed correctly. Interesting is that this is not needed for mingw makefiles. I also do not know how to set the RANLIB properly in my toolchain file.   Either way, the : is obviously the default for noop

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-118-gfcd706a

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 fcd706a47df8800fb7ad6cfac783ea40f184f4e5 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-120-g15e1ee7

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 15e1ee72d6d13ab02cbfd727a5702a7ce8bd18a2 (commit) via

Re: [cmake-developers] [patch] FindBZip2: Add additional debug library name

On 06/07/2016 05:54 PM, Roger Leigh wrote: > I've merged this bzip2-debug-names branch into next for testing. Looks good, thanks. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various

Re: [cmake-developers] cmLocalGenerator::GetTargetFlags

Hi Tobias, So it looks like I was completely wrong in pointing you at GetTargetFlags to get compiler flags. It is indeed for linker flags. On 06/08/2016 04:23 AM, Tobias Hunger wrote: > what use is the "flags" out-parameter in cmLocalGenerator::GetTargetFlags? It > is > only ever set for

Re: [cmake-developers] CMake daemon-mode

On 06/08/2016 04:05 AM, Stephen Kelly wrote: > I have rebased it and force pushed my github branch (there are a few > rebasing mistakes which I'll remove later). Thanks. > We hit issues at work that different clang-format versions have > different behavior. There we have the luxury of providing

Re: [cmake-developers] CMake daemon-mode

On 06/08/2016 01:24 AM, Tobias Hunger wrote: >> cmLocalGenerator: Pass configuration to GetTargetFlags >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241 > > Great, thanks! I had to revert it from 'next' because it caused several LinkFlags test failures. The reason is that it

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-149-g03a75bf

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 03a75bf379f0af616975da7421ea95ee669ee8b9 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-68-g3969994

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