[Cmake-commits] CMake branch, master, updated. v3.7.2-1148-g7b4514f

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

Re: [CMake] ExternalProject_Add

That is a good point. I found that a side effect of the superbuild is that my project can be built independently and I can distribute it without the superbuild parent project. Thanks Nicholas! On Sun, Jan 22, 2017 at 10:33 PM Nicholas Braden wrote: > Yes, that is

Re: [CMake] ExternalProject_Add

Yes, that is what I do in my superbuilds. Generally I make is such that my project could be built without the superbuild, and the superbuild is just a convenience. On Sat, Jan 21, 2017 at 12:17 PM, Saad Khattak wrote: > >> One possibility is the often mentioned superbuild

[Cmake-commits] CMake branch, next, updated. v3.7.2-2285-g69cd1ce

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

Re: [CMake] Interfacing cmake with 3rdparties package manager, and exclude them from ninja clean

Hello,Tx for the idea !That would work to "boostrap" the build but I'm not very fond of it due to it's "static" nature : it would run only once during the initial cmake run.We extract versionning information from git tags : in our current (slow) build system, a git update can trigger a "rpm"