[Cmake-commits] CMake branch, next, updated. v3.8.0-rc4-707-g0615326

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 discards 944a07e4098cbfc3dc112819ff23115e83e3f354 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.8.0-rc4-704-gc8208c9

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 c8208c95a706fcfddb46f35c0b77e3c0d93ad750 (commit) from

[Cmake-commits] CMake branch, nightly-master, updated. v3.8.0-rc4-703-gfe81c03

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

[Cmake-commits] CMake branch, nightly, updated. v3.8.0-rc4-706-g944a07e

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, nightly has been updated discards c7d6ba9119b0fee7716190401c1941b7130f81b6 (commit) via

[CMake] .so link and cpack

Currently, I have a project where I build a library and an executable that depends on the library. Finally, I package a .deb package with cpack. Now, my problem is that cpack packs the symbolic link of my library and that creates problems with the deb installer ( dpkg -i ) whenever I try to

Re: [CMake] ExternalProject_Add and include_external_msproject dynamic duo... but what if their powers combined?

crickets crickets... crickets... That's the response I get from the internet? Here are some other interesting bits: https://cmake.org/cmake/help/v3.8/manual/cmake-packages.7.html Does not make any reference to configure_package_config_file in

Re: [CMake] cmake -E remove -f

After taking a look at the source code, I'm convinced this option is questionable. Issue created in gitlab here . On Thu, Apr 6, 2017 at 9:35 AM, Craig Scott wrote: > Yes, but in both cases the directory foo is still