[Cmake-commits] CMake branch, master, updated. v3.6.0-rc3-235-gf05657d

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

Re: [cmake-developers] daemon-mode meeting last Tuesday

Hi Rolf, Am 23.06.2016 23:00 schrieb "Rolf Eike Beer" : > What about just passing --server-fd= into it? That way the client can set > up whatever if wants to pass there and CMake has nothing to do with any setup. > And if one really wants to get messy one could pass a tty there.

Re: [cmake-developers] daemon-mode meeting last Tuesday

Hi Ben, Am 23.06.2016 22:48 schrieb "Ben Boeckel" : > cmake-oracle sounds reasonable for what it's doing to me. I hope this thing will provide information more reliable than e.g. the Oracle of Delphi in ancient Greece:-) Best Regards, Tobias -- Powered by

Re: [cmake-developers] daemon-mode meeting last Tuesday

Am 23.06.2016 22:46 schrieb "Brad King" : > > On 06/23/2016 08:27 AM, Tobias Hunger wrote: > Great! Thanks for the detailed summary of the meeting and status of the design. You are welcome. > > * Some names could be improved. Suggestions welcome. > > We'll cover these

Re: [cmake-developers] daemon-mode: Infrastructure

On Tue, Jun 14, 2016 at 02:00:14 +0200, Tobias Hunger wrote: > Implementing new Protocol Versions: > == > Deprecating old Protocol Versions: > One idea that came up on a previous project was the following: namespace protocol {

Re: [cmake-developers] daemon-mode meeting last Tuesday

> 1.1 Communication: > > * Clients should talk to daemon mode via a socket (libuv supports that), > but we also want to support stdin/stdout at least for a "debug mode" * > There should be a separate command line switch to start stdin/out mode and > for socket mode > * This is needed

Re: [cmake-developers] daemon-mode meeting last Tuesday

On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote: > On 06/23/2016 08:27 AM, Tobias Hunger wrote: > > * Figure out whether a PDB file is actually going to be build. Currently > > the PDB file is added to the list of artifacts whenever there is a .lib > > file, which is probably

Re: [cmake-developers] daemon-mode meeting last Tuesday

On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote: > On 06/23/2016 08:27 AM, Tobias Hunger wrote: > > * Some names could be improved. Suggestions welcome. > > We'll cover these in more detail during review. The most important name is > the name of the feature, and IMO "daemon" is not an

Re: [cmake-developers] daemon-mode meeting last Tuesday

On 06/23/2016 08:27 AM, Tobias Hunger wrote: > Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch we > both have been working on. It was a very productive meeting: We managed to > resolve almost all the differences of opinion we had. Great! Thanks for the detailed summary

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-523-g272f159

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-521-gf8955ba

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

Re: [cmake-developers] [PATCH] Update documentation for VERSION and SOVERSION for Mach-O file formats (OSX, iOS, BSD etc.)

On 06/23/2016 11:50 AM, Bartosz Kosiorek wrote: > how to set "current version" and "compatibility version" on > binaries produced by OS X. > I have updated documentation to describe how to archieve that Thanks. I revised the changes a bit and applied the patch: Help: Describe VERSION and

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-517-gc480bac

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

[CMake] What is the best way to *export* the transitive dependencies of a library?

Say the executable Exe uses some static library Foo which uses other libraries, e. g. Bar: Exe --> Foo --> Bar As the developer of Foo and I want to make it easy to link against: find_package(Foo REQUIRED) target_link_libraries(Exe PRIVATE Foo) The problem lies with the various

[cmake-developers] [PATCH] Update documentation for VERSION and SOVERSION for Mach-O file formats (OSX, iOS, BSD etc.)

Hello. Last time I faced problem, how to set "current version" and "compatibility version" on binaries produced by OS X. I have updated documentation to describe how to archieve that, to make life easier for new CMake users. Please let me know what do you think about it. Do you think it could

Re: [CMake] gathering directory names in cmake

Alas, this has no effect. Consider the following shell script: - #!/bin/sh if [ -d attempt ] ; then rm -rf attempt ; fi mkdir attempt cd attempt for d in src src/app src/plugins/one ; do mkdir -p $d/xyz touch $d/xyz/one.txt

Re: [cmake-developers] patch for FindProtobuf.cmake

On 06/22/2016 08:08 PM, Miroslav Drahos wrote: > I believe I found a bug in FindProtobuf.cmake. Using set with two > parameters will insert an unwanted semicolon, the list separator. > The changes I made are like this (several occurrences): > > -set(_protobuf_include_path -I

Re: [cmake-developers] handling components in Find****

On 06/22/2016 08:11 AM, Farbos a wrote: > I am trying to write a Find module with components and I am not sure > of how it should be written. > I attached the find module, Could someone tell me if I did it well? It looks okay to me from a quick glance. Side note: For variables private to the

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-515-g6c53085

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-513-g57bc268

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc3-234-gc2c2a2f

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc3-230-gf101d4e

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc3-232-g015876f

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-509-g94c1645

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

Re: [CMake] CXX_STANDARD and -std=c++14

At the risk of repeating myself... it's a non-intuitive "gotcha" that set_property(TARGET target PROPERTY CXX_STANDARD 14) results in something OTHER than the C++14 standard. The issue is likely to continue tripping people up, resulting in continued posts to this email list. If you want

Re: [CMake] Compiling binaries with cmake -- help

Yep, if you have all the dependencies it should just work as I described in a previous message. On Thu, Jun 23, 2016 at 12:20 AM, Crest Christopher wrote: > I'll get the Python sipconfig module installed, then I hope we can continue > with getting it compiled ? > >

Re: [CMake] CXX_STANDARD and -std=c++14

Thanks, Nicholas. Might be worth adding a link to that from this page. https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html?highlight=cxx_standard On 23 June 2016 at 14:34, Nicholas Braden wrote: > This was asked recently - have a look at the

Re: [CMake] CXX_STANDARD and -std=c++14

This was asked recently - have a look at the CXX_EXTENSIONS property: https://cmake.org/cmake/help/latest/prop_tgt/CXX_EXTENSIONS.html Previous discussion: http://public.kitware.com/pipermail/cmake/2016-June/063691.html On Thu, Jun 23, 2016 at 7:27 AM, James Swift wrote: >

[CMake] CXX_STANDARD and -std=c++14

Hi, is there a way (or can it be added) to get set_property(TARGET target PROPERTY CXX_STANDARD 14) to output -std=c++14 and not -std=gnu++14 when needed? Thanks, James Swift -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

[cmake-developers] daemon-mode meeting last Tuesday

Hello CMake Developers, Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch we both have been working on. It was a very productive meeting: We managed to resolve almost all the differences of opinion we had. Here is a short summary of what we talked about: 0) General   *

Re: [CMake] C header file cross dependency

Hi Patrick, thank you for your answer and sorry that it took me a while to work on it. > > I forked your repo and played a little bit around. > > https://github.com/pboettch/test_cmake I pulled those changes and played aroud a bit myself. https://github.com/martinwag/test_cmake I'm now back