[CMake] 'CPACK_RPM_PACKAGE_AUTOPROV' doesn't work when pack existing binaries with CPack

Hi, In my project, I use cmake to construct the building system, I need to build an external project(here, I take zeromq for example) with ExternalProject_add, then pack the compiled binaries in a RPM package, but I need the generated RPM to have correct "PROVIDES" information to tell which

Re: [CMake] 'CPACK_RPM_PACKAGE_AUTOPROV' doesn't work when pack existing binaries with CPack

> Does someone know why this "CPACK_RPM_PACKAGE_AUTOPROV" option doesn't take > effect? how can I make it auto generates these 'PROVIDES' information in the > RPM? thanks for your time and it will be very appreciated if you can > provide some hints. CPackRPM relies on rpmbuild and other rpm

[CMake] Delete CDash project

Does anyone know how to delete a CDash project? There doesn't seem to be any way to do this on the website. Thanks! Aaron -- 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 services to support the

Re: [CMake] Visual Studio + Ninja?

Thanks for the feedback. I know for sure that you can create "Makefile" projects in Visual Studio, that do nothing but run commands. You can even still have files in the project itself, to allow you to edit those files (even though they won't actually build). I think CMake can use this

Re: [CMake] Delete CDash project

Never mind - you can do this using the not very obvious "unsubscribe" option in manage subscription. On Fri, Mar 25, 2016 at 10:43 AM, Aaron Boxer wrote: > Does anyone know how to delete a CDash project? There doesn't seem to be > any way to do this on the website. > >

Re: [CMake] CMAKE_SIZEOF_VOID_P is unset when building libgit2 on Windows

On 3/24/2016 16:53, Brad King wrote: Configuring libgit2 fails as CMake does not set CMAKE_SIZEOF_VOID_P (nor CMAKE_C_SIZEOF_DATA_PTR), see the attached CMakeCCompiler.cmake file. I tried to search CMake's source code to find out how the value of @CMAKE_C_SIZEOF_DATA_PTR@ is determined in

Re: [CMake] CMAKE_SIZEOF_VOID_P is unset when building libgit2 on Windows

On 25/03/16 22:11, Sebastian Schuberth wrote: > I also just realized CMAKE_C_ABI_COMPILER is set to FALSE in > CMakeCCompiler.cmake. Looking at CMakeError.log was a good hint. I > found: > > ---8<--- > Building C object CMakeFiles/cmTC_c0166.dir/CMakeCCompilerABI.c.obj > >

[CMake] Support for colored makefile output with tmux

When I use tmux and set my TERM to either 'tmux' or 'tmux-256color', I don't get colorized output of from cmake generated Makefiles. Is this a known issue? On 4.4.5-1-ARCH w/ CMake 3.5.0 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [CMake] Fortran submodule cannot be built

On 03/24/2016 03:32 PM, Brad King wrote: > CMake's approximate Fortran parser will need to be > updated to account for submodule syntax. I don't know if/when I'll have time to look at this myself. If anyone is interested in working on it, please come to the [developer

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

Am 24.03.2016 16:13 schrieb "Aleix Pol" : > Hey, > I'll be going to Berlin the weekend of the 14th May (Board meeting, > I'll be busy during the weekend). > > Would it make sense for me to book one day before/after to meet and > hack on this? Hey Aleix, I did already do some

[Cmake-commits] CMake branch, next, updated. v3.5.1-653-g2632c2f

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

[Cmake-commits] CMake branch, master, updated. v3.5.1-319-g06a8dc7

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

[Cmake-commits] CMake branch, next, updated. v3.5.1-655-g7d8ab1b

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

[Cmake-commits] CMake branch, next, updated. v3.5.1-657-g021e01c

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

Re: [cmake-developers] [CMake 0016030]: CMAKE_ASM_NASM_COMPILE_OBJECT lacks

On 25/03/16 19:28, Brad King wrote: > On 03/25/2016 01:46 PM, Gregor Jasny via cmake-developers wrote: >> Does anyone see a reason to *not* prepend all with a ? > > I'm not particularly familiar with the ASM tooling landscape but > that prepend step is exactly what was done for all other

[Cmake-commits] CMake branch, master, updated. v3.5.1-320-g9b56528

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

Re: [cmake-developers] [CMake 0016030]: CMAKE_ASM_NASM_COMPILE_OBJECT lacks

On 03/25/2016 01:46 PM, Gregor Jasny via cmake-developers wrote: > Does anyone see a reason to *not* prepend all with a ? I'm not particularly familiar with the ASM tooling landscape but that prepend step is exactly what was done for all other languages in commit v3.4.0-rc1~342^2 (Factor an

Re: [cmake-developers] [CMake 0016030]: CMAKE_ASM_NASM_COMPILE_OBJECT lacks

Hello, On 22/03/16 17:10, Mantis Bug Tracker wrote: > Starting with CMake 3.4 the ASM_NASM language does not pass forward > include_directories(XYZ) to the nasm compiler line. > > As far as I can see is missing for other assemblers as well. When I grep for CMAKE_ASM * _COMPILE_OBJECT I get the

Re: [cmake-developers] [PATCH] Ninja: Optionally skip library dependencies for object targets

On Tue, Mar 15, 2016 at 10:06:12 -0400, Brad King wrote: > add_custom_command(OUTPUT foo.h ...) > add_library(foo foo.c foo.h) > add_library(bar bar.c) > target_link_libraries(bar foo) > > The order-only dependency of `bar.c.o` on the target `foo` is just > in case `bar.c` needs to