[Cmake-commits] CMake branch, master, updated. v3.11.0-rc1-61-g4e6f94d

VERSION_MINOR 11) -set(CMake_VERSION_PATCH 20180220) +set(CMake_VERSION_PATCH 20180221) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] Latest versions of CMake/Qt Creator lock up configuration on CMake error

Haocheng, Yes, if I go to the CMake GUI, use that to set all the CMake variables so that the configure succeeds, and then load that configuration into Qt Creator, everything works fine. The problem is only when CMake configuration fails because a variable needs to change. The common case where

Re: [CMake] Latest versions of CMake/Qt Creator lock up configuration on CMake error

Hi Ken, On Tue, Feb 20, 2018 at 4:08 PM, Moreland, Kenneth wrote: > This might be a question for the folks at Qt, but I thought I would float > it here first as other CMake users might have run into it. > > > > This morning I updated to the most recent versions of CMake

[CMake] Latest versions of CMake/Qt Creator lock up configuration on CMake error

This might be a question for the folks at Qt, but I thought I would float it here first as other CMake users might have run into it. This morning I updated to the most recent versions of CMake (3.10.2) and Qt Creator (4.5.1). I then tried to use Qt Creator to configure a non-trivial CMake

[Cmake-commits] CMake branch, master, updated. v3.11.0-rc1-60-gb892526

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

[Cmake-commits] CMake branch, release, updated. v3.11.0-rc1-4-g82c23d6

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, release has been updated via 82c23d6afcc862f3000607ab1521e72ca743a3b0 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.11.0-rc1-57-ga8d182f

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

[Cmake-commits] CMake branch, master, updated. v3.11.0-rc1-49-g3bc3762

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

Re: [CMake] [blog article] It's Time To Do CMake Right

Indeed. Our CMake build here is spread across >500 list files with around 1G of source code. I've often wondered how it compared to other large C and assembly projects. To wit, several of the practices in the article we've followed as well. It's great to hear that someone is working on a book -

Re: [CMake] [blog article] It's Time To Do CMake Right

Kai Wolf writes: > As a shameless self-plug: I am currently writing a book[1] on exact this > topic and really hope, I'll be able to release it by summer 2018 :-( > [1] http://effective-cmake.com/ This is great to hear! --

Re: [CMake] [blog article] It's Time To Do CMake Right

​Well, sounds like a reasonably sized C++ project :-) On a more serious note: Are you aware of so called Superbuilds? This is a term that is used quite often in the context of large CMake based dependency builds. Speaking from personal experience, I've found that Superbuild projects do scale

Re: [CMake] [blog article] It's Time To Do CMake Right

On Tuesday, 20 February 2018 14:59:10 CET Kai Wolf wrote: > Nice, > > ​I've found a smaller issue though. I've just submitted a PR on GitHub. > The reddit discussion is also interesting. A common theme in the typical > "CMake is bad" discussions is not the lack of documentation​, but a good >

Re: [CMake] [blog article] It's Time To Do CMake Right

Nice, ​I've found a smaller issue though. I've just submitted a PR on GitHub. The reddit discussion is also interesting. A common theme in the typical "CMake is bad" discussions is not the lack of documentation​, but a good tutorial on how to *actually accomplish things* using CMake in a correct

[CMake] [blog article] It's Time To Do CMake Right

Hi, I thought the audience here would appreciate this: https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ It did quite a stir on /r/cpp too: https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/ Cheers, Cristian. -- Powered by www.kitware.com Please keep

Re: [CMake] Ignore installation failure

On Sun, 18 Feb 2018, David Adam wrote: > Our project installs an empty directory for other programs to drop files > in, the location of which is overrideable with a cache variable. Some > environments set the location of this directory outside the writeable > area and create it themselves, so

Re: [cmake-developers] CMake build with static crt and static QtDialog not linking

Hi Michael, Be aware of VS2017 issues with variables initialization during static build (in Qt in particular). See for more info: https://developercommunity.visualstudio.com/content/problem/76198/vs-2017-compiler-creates-broken-debug-build-using.html https://bugreports.qt.io/browse/QTBUG-66140