[Cmake-commits] CMake branch, master, updated. v3.6.0-rc2-175-g2e351f8

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

[cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio

This patch is to add the ability with Visual Studio generators to add references to SDKs. This is similar to the DESKTOP, IOT and MOBILE extensions for Windows 10, but makes the process more generic, using the Property VS_SDK_REFERENCES as a semi-colon separated list. For example, adding a

[cmake-developers] Patch: Add ability to override the default Visual Studio tool

This patch is to add the ability to override the default tool assigned by the Visual Studio generator based on the extension, by using a new source property VS_TOOL_OVERRIDE. This also allows for new tools to be defined without having to teach CMake how to handle them. For example, this allows

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

On 06/13/2016 08:00 PM, Tobias Hunger wrote: > * There will always be 1 client talking to a server. > * Client/Server communicate using JSON messages Yes. IIRC it is using stdin/stdout (I haven't checked the code), so limiting to one client is implicit. In this case, is it actually a daemon?

Re: [cmake-developers] CMake daemon-mode

On 06/10/2016 12:31 PM, Tobias Hunger wrote: > I did try to do the changes you requested. The branch is here: > https://github.com/hunger/CMake/commits/compileflags Thanks. I did some refactoring to help address the path conversion problem: Refactor Makefile/Ninja tool working directory

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-403-gaf3d9d4

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-397-g3817aa9

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-395-g94a1d96

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc2-174-g0420cb4

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-393-geb21776

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-391-g74bef6f

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-389-ge8815ce

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-387-gef86b0e

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

Re: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path

On 06/17/2016 01:33 PM, Christian Schmidbauer wrote: >> CMake sets the lib32/lib64 ones in its own >> platform modules for the relevant platforms so user code never >> needs to do it. Where in user code would it be done? > > In my setup, I would create a custom my-config.cmake file And that is

Re: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path

On Fri, Jun 17, 2016 at 7:13 PM, Brad King wrote: > On 06/17/2016 12:53 PM, Christian Schmidbauer wrote: >>> Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item documentation, >>> or whatever it becomes after the discussion below. >>> >> Where do you want me to document

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

On 6/17/2016 1:12 PM, Brad King wrote: On 06/17/2016 01:02 PM, Stuart Mentzer wrote: Thanks but a line was lost in translation at the bottom: mark_as_advanced( *FREETYPE_LIBRARY* FREETYPE_INCLUDE_DIR_freetype2 FREETYPE_INCLUDE_DIR_ft2build ) SLC handles mark_as_advanced for the

Re: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path

On 06/17/2016 12:53 PM, Christian Schmidbauer wrote: >> Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item documentation, >> or whatever it becomes after the discussion below. >> > Where do you want me to document it? In the same places that FIND_LIBRARY_USE_LIB32_PATHS documentation was

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

On 06/17/2016 01:02 PM, Stuart Mentzer wrote: > Thanks but a line was lost in translation at the bottom: > > mark_as_advanced( > *FREETYPE_LIBRARY* > FREETYPE_INCLUDE_DIR_freetype2 > FREETYPE_INCLUDE_DIR_ft2build > ) > > SLC handles mark_as_advanced for the _DEBUG and _RELEASE variables >

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

Am Freitag, 17. Juni 2016, 13:02:30 schrieb Stuart Mentzer: > On 6/17/2016 11:54 AM, Brad King wrote: > On 06/12/2016 01:52 PM, Stuart Mentzer wrote: > Looking at FindZlib.cmake I think the attached should be OK > Thanks. I've applied that as a patch here: > > FindFreetype: Find release and

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

On 6/17/2016 11:54 AM, Brad King wrote: On 06/12/2016 01:52 PM, Stuart Mentzer wrote: Looking at FindZlib.cmake I think the attached should be OK Thanks. I've applied that as a patch here: FindFreetype: Find release and debug libraries

Re: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path

On Mon, Jun 13, 2016 at 5:22 PM, Brad King wrote: > Hi Christian, > > Thanks for working on this. > > On 06/12/2016 05:59 AM, Christian Schmidbauer wrote: >> A similar idea has already been suggested in #10287 > > Yes. > >> and is required for bug #15594. > > That issue

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-385-gcc24cf9

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

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

On 06/12/2016 01:52 PM, Stuart Mentzer wrote: > Looking at FindZlib.cmake I think the attached should be OK Thanks. I've applied that as a patch here: FindFreetype: Find release and debug libraries separately https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b213a7f6 -Brad -- Powered by

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-383-g67d41ab

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

Re: [cmake-developers] codeblocks generator: Fix include directories being in unexpected order

On 06/17/2016 03:31 AM, Tobias Hunger wrote: > Could this please go into 3.6? > > This is the root cause of quite a few bug reports hitting Qt Creator bug > tracker > right now, so I would love to see a fix out in the wild ASAP. Normally I don't make non-regression/doc fixes after the first RC

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-381-gf6ee4ac

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc2-172-g9e47255

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc2-165-ge4cb7d7

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc2-160-g44f81be

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc2-162-g5889eb4

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc2-158-g9ef7ccd

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-374-gcee12ec

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-372-g8a827d1

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-370-g541633c

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-368-ga094bf6

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-366-gf5a7245

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

[CMake] Question about CHECK_C_COMPILER_FLAG

Hi All, I have a question about CHECK_C_COMPILER_FLAG behaviour. Documentation will tell that "the compiler does not give an error message when it encounters the flag". Unfortunately, it not only compiles but try to link executable. If linker fails, due missed libraries it also does not produce

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-360-gd932507

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-358-gef0d8c3

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

Re: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

On Fri, Jun 17, 2016 at 15:40:45 +0200, Nils Gladitz wrote: > I have not been involved in that development. > From what I can tell this is Eike's work. Ack, sorry. Should have double checked. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

On 06/17/2016 09:40 AM, Nils Gladitz wrote: > On 06/17/2016 03:36 PM, Ben Boeckel wrote: >> Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks >> for that. However, it is hidden behind the check that pkg_check_modules >> uses to see if it already ran: > > From what I can tell

Re: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

Am 2016-06-17 15:36, schrieb Ben Boeckel: Hi, Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks for that. However, it is hidden behind the check that pkg_check_modules uses to see if it already ran: if (NOT DEFINED __pkg_config_checked_${_prefix} OR

Re: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

On 06/17/2016 03:36 PM, Ben Boeckel wrote: Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks for that. However, it is hidden behind the check that pkg_check_modules uses to see if it already ran: I have not been involved in that development. From what I can tell this is

[cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

Hi, Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks for that. However, it is hidden behind the check that pkg_check_modules uses to see if it already ran: if (NOT DEFINED __pkg_config_checked_${_prefix} OR __pkg_config_checked_${_prefix} LESS

Re: [CMake] cmake install target doesn't run ldconfig after installing library

So I did some experimenting. It would seem there are a few rules to the order installs are executed 1 - installs are processed in the order the containing CMakeLists.txt files are 2 - within a CMakeLists.txt they seem to be ordered based on which comes first in the file. So a not so elegant

Re: [cmake-developers] Toward a more deterministic ninja generator

On Thu, Jun 16, 2016 at 7:14 PM, Brad King wrote: > On 06/14/2016 11:18 AM, Nicolas Desprès wrote: > > It makes the ninja generator more deterministic by sorting the > > build edge's inputs/outputs. It does not introduce any > > regression on my macbookpro. > > > > This

Re: [cmake-developers] codeblocks generator: Fix include directories being in unexpected order

On Do, 2016-06-16 at 13:14 -0400, Brad King wrote: > On 06/14/2016 11:52 AM, Tobias Hunger wrote: > > https://github.com/hunger/CMake/commit/f190b069db2e430fd94b25e6287cd7fbc2866 > > 1e3 > > > > Is the same thing updated based on suggestions from Stephen. > > Thanks, applied: > >