[Cmake-commits] CMake branch, next, updated. v3.3.1-2896-ge81aa1a

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1162-g31117bb

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

[cmake-developers] [CPackDeb] use of internal md5sum function

Hi Brad and Domen and others, Please find attached a patch on CPackDeb - which calls the internal function for md5sum computation - which prevents the hash of the symlinks I believe this fixes the issue (partially or totally) https://public.kitware.com/Bug/view.php?id=13386 It is based on my

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

Le 14/09/15 11:51, Raffi Enficiaud a écrit : Hi Brad and Domen and others, I just realized that the permissions for the extra control files should be set in a different way than for the md5sum checksum file. Please find attached the patch correcting this and the corresponding test that fires

[Cmake-commits] CMake branch, master, updated. v3.3.1-1153-g8af3474

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1164-gf660a68

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2894-g6f95ab5

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1166-g6dad4c2

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2885-g993e178

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1157-g75ad8d3

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

[Cmake-commits] CMake branch, master, updated. v3.3.1-1155-ge32604d

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

[cmake-developers] [CMake 0015742]: string(REGEX MATCH) and string(REGEX MATCHALL) concatenate arguments

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15742 == Reported By:Fujii Hironori Assigned To:

[cmake-developers] [CPackDeb] empty directories in packages

Hi Brad and Domen and others, I was looking at this issue http://public.kitware.com/Bug/view.php?id=13009 and apparently it is not possible to install empty directories (I just tested). I believe that it should be possible to do that (even if there are better ways like postinst). What is

Re: [cmake-developers] Python extension to FindProtobuf

On 09/14/2015 03:42 AM, Andreas Bergmeier wrote: > I now added documentation, removed ARGS and GENERATED property. Thanks. Applied with minor wording tweaks: FindProtobuf: Add protobuf_generate_python function http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=143579c3 -Brad -- Powered by

[Cmake-commits] CMake branch, next, updated. v3.3.1-2899-g6e4c900

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

Re: [cmake-developers] Portability patches / bug fixes

On 09/12/2015 11:03 AM, Joerg Sonnenberger wrote: > attached are three patches for cmake. The first two should be trivial > and self-explaining. The third is a more involved change for ccmake. Thanks. I've applied the changes: jsoncpp: Fix compilation as C99 on Solaris

[Cmake-commits] CMake branch, next, updated. v3.3.1-2912-g53ec406

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

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

On 09/14/2015 03:05 AM, CHEVRIER, Marc wrote: > Any news on this subject? Chuck has had a fix in 'next' for a few days: find_*: Fix search order when the environment duplicates some HINTS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec8e5fb3 but the topic is still missing a test case.

[Cmake-commits] CMake branch, next, updated. v3.3.1-2901-ge9b1715

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2905-gc8c7983

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2910-ga01af51

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2907-gec5077c

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

Re: [CMake] FindGit.cmake proposal

Hello, On 10/09/15 16:34, Daniel Wirtz wrote: > i've now quite often encountered the need to access basic git > information about the source tree from within cmake. > i've attached the current FindGit.cmake module shipped with CMake > enhanced by two functions: getGitRevision and getGitBranch. >

Re: [cmake-developers] Listing all targets

Finally getting back to this, hopefully can push to next this week, and have this completed in time for the upcoming 3.4 release. I have three questions before attempting my first merge-to-next for testing: (1) I see how I can easily move "COMPONENTS" from cmGetCMakePropertyCommand::InitialPass

[cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

As of version 3.3.1, CMake sets CMAKE_C11_STANDARD_COMPILE_OPTION and CMAKE_C11_EXTENSION_COMPILE_OPTION for GCC >= 4.7, and checks for C11 features for GCC >= 4.6. It also means CMake itself will be built with -std=gnu11 if GCC >= 4.7 is used. However, GCC only has full C11 support with the 4.9

[Cmake-commits] CMake branch, next, updated. v3.3.1-2914-gab5441a

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2917-g37278dc

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

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Raphael Kubo da Costa wrote: > Adjust the GCC feature detection code to only consider C11 support to > exist on GCC >= 4.9. If you do that you must remove the definition of CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too. IOW, this patch is not correct, and should not be merged.

Re: [cmake-developers] Listing all targets

On 09/14/2015 11:46 AM, David Cole wrote: > (1) I see how I can easily move "COMPONENTS" from > cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty > because I can access the global generator from cmState as well... Yes. > move "VARIABLES" and "MACROS," though, I need access to

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

Michael Scott wrote: > Hi, > > I'm planning on having a look at the CMake issue "Allow ALIAS of > IMPORTED targets", 0015569. After reading the thread between yourself > and Marc, I wanted to ask a couple of things before I start going > further with it. Thanks for working on this. > The

[Cmake-commits] CMake branch, next, updated. v3.3.1-2931-g664a9b0

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

Le 14/09/15 23:34, Domen Vrankar a écrit : Thank you. However those two test are not mutually exclusive. I think having them on lintian is also a good thing. I've tried your test change before but lintian test complained that 775 are invalid permissions (should be 755). Is this caused by a

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

Hi Domen, Thank you. However those two test are not mutually exclusive. I think having them on lintian is also a good thing. Best and thanks, Raffi Le 14/09/15 23:19, Domen Vrankar a écrit : I just realized that the permissions for the extra control files should be set in a different way

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

>> I just realized that the permissions for the extra control files should >> be set in a different way than for the md5sum checksum file. >> >> Please find attached the patch correcting this and the corresponding >> test that fires the problem. Thanks, applied the fix:

Re: [CMake] Need help with COMPILE_DEFINITIONS_

Hello, Have you tried set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG -DATEST) ? On Mon, Sep 14, 2015 at 9:35 PM, Carl Poirier wrote: > Hi folks, > > I need some help setting the COMPILE_DEFINITIONS_. I'm using the > Visual Studio 2008

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

> Thank you. However those two test are not mutually exclusive. I think having > them on lintian is also a good thing. I've tried your test change before but lintian test complained that 775 are invalid permissions (should be 755). Is this caused by a different version of lintian or should I just

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

> For example, if an ALIAS can be IMPORTED, does it makes sense that it can be > exported with export() and install(EXPORT)? Yes: couple of months ago I was adding install(EXPORT) to an existing CMakeList. The name of the library target which I had to export was not correct as export target name

[Cmake-commits] CMake branch, next, updated. v3.3.1-2928-g9f5b349

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

Re: [CMake] Need help with COMPILE_DEFINITIONS_

Am 14. September 2015 22:25:00 MESZ, schrieb Pau Garcia i Quiles : >Hello, > >Have you tried > >set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG >-DATEST) That would be the right thing for add_definitions() but not here. He could try with generator

Re: [cmake-developers] CMake user-provided manifest files

On 09/11/2015 03:02 PM, Brad King wrote: > On 09/11/2015 02:09 PM, Brad King wrote: >> I would be very happy to get rid of the vs_link_exe and vs_link_dll code. > > There is documentation here about what those are doing: > > https://msdn.microsoft.com/en-us/library/ms235591.aspx >

[CMake] FindPythonLibs patches for version searching and frameworks

Hi All, I've attached three suggested patches for cmake. The first is trivial, it simply adds Python 3.5 and 3.6 to the search list. The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion for PYTHON_INCLUDE_DIR. The third does two important things: 1) it fixes bugs for

[Cmake-commits] CMake branch, master, updated. v3.3.1-1169-g075de28

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

Re: [CMake] fixup_bundles on macosx for non-.app target

Sorry for the delay. https://github.com/dream3d/DREAM3D/tree/develop/Support/cmp/OSX_Tools the CompleteTool.cmake.in calls the CompleteTool.sh.in files through a custom cmake command after they are "Configured" through "configure_file". I think you can figure out what is going on. There may

[Cmake-commits] CMake branch, master, updated. v3.3.1-1168-g050a14f

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

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

Hi Michael, If this feature can be supported for libraries and executables, it will be perfect for me. Thank you. Marc On 12/09/15 23:48, "cmake-developers on behalf of Michael Scott" wrote: >Hi, > >I'm planning

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

Any news on this subject? I think it is a critical bug because behaviour is broken. So I cannot rely on find_executable anymore to get the expected program! Marc On 09/09/15 20:20, "Brad King" wrote: >On 09/09/2015 11:50 AM, Chuck Atkins wrote: >> From what I can

Re: [cmake-developers] Python extension to FindProtobuf

I now added documentation, removed ARGS and GENERATED property. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Freitag, 11. September 2015 20:33 To: Andreas Bergmeier Cc: Rolf Eike Beer; cmake-developers@cmake.org Subject: Re: [cmake-developers] Python extension

Re: [cmake-developers] Listing all targets

Brad King wrote: > On 09/14/2015 11:46 AM, David Cole wrote: >> (1) I see how I can easily move "COMPONENTS" from >> cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty >> because I can access the global generator from cmState as well... > > Yes. I assume you're thinking of

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

On 09/14/2015 01:53 PM, Raphael Kubo da Costa wrote: > Especially if you take into account the > CMAKE_CXX11_STANDARD_COMPILE_OPTION argument, one could argue that this > is about choosing how strict CMake should be when determining whether a > compiler implements a standard: enabling C++11

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Stephen Kelly writes: > Raphael Kubo da Costa wrote: > >> Adjust the GCC feature detection code to only consider C11 support to >> exist on GCC >= 4.9. > > If you do that you must remove the definition of > CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too. [...] >

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

On 09/14/2015 02:00 PM, Alan W. Irwin wrote: > Because this find regression is against 3.1.3 from what Marc said, may > I assume you are planning to include the fix for this regression in > both future cmake-3.2.x and 3.3.y releases? We may backport it for a possible 3.3.2 but there will be no

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Brad King writes: > In this case CMake itself cannot build with C11 on this compiler/platform > combination so we should not try to do so. We already have some checks > here: > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeLists.txt;hb=v3.3.1#l39 > > to decide

[Cmake-commits] CMake branch, next, updated. v3.3.1-2919-gef34192

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

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

On 2015-09-14 10:51-0400 Brad King wrote: On 09/14/2015 03:05 AM, CHEVRIER, Marc wrote: Any news on this subject? Chuck has had a fix in 'next' for a few days: find_*: Fix search order when the environment duplicates some HINTS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec8e5fb3

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

On 09/14/2015 02:29 PM, Raphael Kubo da Costa wrote: > Do you mean checking for FreeBSD and compiler version? I thought it'd be > too specific for upstream and was just going to make it be built with a > different standard (or no standard) on FreeBSD itself. I meant to add a try_compile check

[CMake] Need help with COMPILE_DEFINITIONS_

Hi folks, I need some help setting the COMPILE_DEFINITIONS_. I'm using the Visual Studio 2008 generator. I use this command to do so which I took in the notes when the feature was added: set_property(TARGET ${PrjName0} PROPERTY

[Cmake-commits] CMake branch, next, updated. v3.3.1-2923-g35f46e3

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

[Cmake-commits] CMake branch, next, updated. v3.3.1-2926-g4653dc3

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

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Raphael Kubo da Costa wrote: > Stephen Kelly writes: > >> Raphael Kubo da Costa wrote: >> >>> Adjust the GCC feature detection code to only consider C11 support to >>> exist on GCC >= 4.9. >> >> If you do that you must remove the definition of >>

[CMake] Libraries for a Target and/or its Dependents

Hello, The docs say [1]: "Libraries and targets following PRIVATE are linked to, but are not made part of the link interface." If so, why does this snippet: add_library(private_lib STATIC ...) add_library(public_lib STATIC ...) target_link_libraries(Test PRIVATE private_lib