[Cmake-commits] CMake branch, master, updated. v3.7.0-510-g1d9934a

2016-11-14 Thread Kitware Robot 
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  1d9934a56a36707a9366043042c3aa3e5ae7d86d (commit)
  from  d608cfb6bf6b93add793c64b40787307be10059a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d9934a56a36707a9366043042c3aa3e5ae7d86d
commit 1d9934a56a36707a9366043042c3aa3e5ae7d86d
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Nov 15 00:01:04 2016 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Nov 15 00:01:04 2016 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 6bee953..b0c9701 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 7)
-set(CMake_VERSION_PATCH 20161114)
+set(CMake_VERSION_PATCH 20161115)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] System is unknown to cmake Platform/MINGW64_NT-6.3

2016-11-14 Thread Stephen Groat 
Received this error message (
https://ci.appveyor.com/project/stephengroat/unicorn/build/1.0.23/job/ybemjtabbbwvab86#L200)
but don't know where to look in the directory for the config file. I'm
running Mingw-w64 with msys and bash.

Any advice?

Thanks,

Stephen
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[cmake-developers] CMAKE 3.7 (for Android target) error: crtbegin_dynamic.o:crtbrand.c:function _start: error: undefined reference to 'main’

2016-11-14 Thread Roberto Regalino 
Hi,

Not sure if this is the place to ask my question but here we go:

I am trying to build C++ code targeting the Android platform. I already have 
the whole system setup to generate VisualStudio projects and it is using the 
Nsight Tegra plug-in.
I’ve been asked to update the CMake files so we can still target Android but 
not using VisualStudio  in hope to migrate to AndroidStudio.
So far, I managed to create a new toolchain file containing the following:

set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang)
set(CMAKE_ANDROID_API 21)
set(CMAKE_ANDROID_NDK $ENV{ANDROID_HOME})
set(CMAKE_ANDROID_SKIP_ANT_STEP 0)
set(CMAKE_ANDROID_JAVA_SOURCE_DIR java)
set(CMAKE_ANDROID_BUILD_SYSTEM GradleBuild)

With these settings, I can successfully compile the whole project source files 
but when I get to the link pass, it fails with the error:
C:/NVPACK/android-ndk-r10e/platforms/android-21/arch-arm/usr/lib/../lib\crtbegin_dynamic.o:crtbrand.c:function
 _start: error: undefined reference to 'main’

I believe that I am missing the equivalent steps that are taken care by the 
“Gradle Build” steps found in the VisualStudio project.
My understanding is that these Gradle steps are responsible for embedding the 
AndroidManifest (that, I’ve been told, will define the ‘main’) and generate the 
apk file from the so.

Is this  indeed what I am missing? Also, can anyone confirm if CMake 3.7 does 
provide the equivalent steps or if I need to define them myself?
Thank you in advance

Regalir
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] Force MSVC runtime for debug builds

2016-11-14 Thread Kim Kryger 
I ran into this today. I tried to use /MD to link against a custom md
library, but because _DEBUG was defined *by CMake* I couldn't use it out of
the box.

Why is CMake defining _DEBUG for MSVC projects anyways? _DEBUG is
automatically defined when using /MDd, and I don't believe it should be
defining it itself. I've had to remove it for multiple projects because
it's making assumptions as to what I want defined.


Default for CMAKE_CXX_FLAGS_DEBUG_INIT
/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1

I don't think that first define should be there.


Reference:
https://github.com/Kitware/CMake/blob/5d29506811c5b75ae48e12de6c317f6440874215/Modules/Platform/Windows-MSVC.cmake#L294
https://msdn.microsoft.com/en-us/library/0b98s6w8.aspx


On Fri, Nov 11, 2016 at 9:42 AM, Stephan Menzel 
wrote:

>
> On Tue, Nov 8, 2016 at 4:21 PM,  wrote:
>>
>> If you are going to use /MD instead of /MDd, then you probably also need
>> to remove the _DEBUG preprocessor flag.
>> IIRC, I've seen cases where defining _DEBUG includes symbols only
>> defined by the debug runtimes.
>>
>> Clint
>>
>
> What a surprise. Removing _DEBUG did the trick. I was under the impression
> _DEBUG only controls Microsoft STL impl's debug iterator stuff but
> apparently it also makes the resulting exe link with /MD rather than /MDd.
> Guess that was wrong.
>
> So yes, problem solved.
>
> Thank you!
>
> Stephan
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v3.7.0-1141-g647c3cd

2016-11-14 Thread Brad King 
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  647c3cd2a114dd3c28cddc6b8e2b0ebd7b0b7431 (commit)
   via  d5b56dd15cd351ce678dc0edf63c72a49ffc5ae3 (commit)
  from  27cbf0c76a37656eb8a755fbe02e4c6a58e8 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=647c3cd2a114dd3c28cddc6b8e2b0ebd7b0b7431
commit 647c3cd2a114dd3c28cddc6b8e2b0ebd7b0b7431
Merge: 27c d5b56dd
Author: Brad King 
AuthorDate: Mon Nov 14 14:51:31 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 14:51:31 2016 -0500

Merge topic 'UseSWIG_USE_BUILD_SHARED_LIBS' into next

d5b56dd1 UseSWIG: Add USE_BUILD_SHARED_LIBS to accepted values for the TYPE 
arg


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5b56dd15cd351ce678dc0edf63c72a49ffc5ae3
commit d5b56dd15cd351ce678dc0edf63c72a49ffc5ae3
Author: Daniele E. Domenichelli 
AuthorDate: Mon Nov 14 18:02:09 2016 +0100
Commit: Daniele E. Domenichelli 
CommitDate: Mon Nov 14 18:02:12 2016 +0100

UseSWIG: Add USE_BUILD_SHARED_LIBS to accepted values for the TYPE arg

The new signature is

  SWIG_ADD_LIBRARY(
   [TYPE ]
   LANGUAGE 
   SOURCES ...
   )

diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
index 0e00506..c5912f8 100644
--- a/Modules/UseSWIG.cmake
+++ b/Modules/UseSWIG.cmake
@@ -10,7 +10,7 @@
 # ::
 #
 #SWIG_ADD_LIBRARY(
-# [TYPE ]
+# [TYPE ]
 # LANGUAGE 
 # SOURCES ...
 # )
@@ -248,6 +248,8 @@ macro(SWIG_ADD_LIBRARY name)
 
   if(NOT DEFINED _SAM_TYPE)
 set(_SAM_TYPE MODULE)
+  elseif("${_SAM_TYPE}" STREQUAL "USE_BUILD_SHARED_LIBS")
+unset(_SAM_TYPE)
   endif()
 
   swig_module_initialize(${name} ${_SAM_LANGUAGE})

---

Summary of changes:
 Modules/UseSWIG.cmake |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] Android variables

2016-11-14 Thread Brad King 
On 11/11/2016 01:51 PM, Brad King wrote:
> Okay, thanks.  I'll investigate how to properly expose this information.

Please see:

https://gitlab.kitware.com/cmake/cmake/merge_requests/254

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] Are the current scoping rules for functions intended and documented?

2016-11-14 Thread Brad King 
On 11/14/2016 10:29 AM, Mario Werner wrote:
> I was just surprised by the scoping rules of CMake when it comes to
> function definitions and sub scopes (i.e., subdirectories). I expected
> that function definitions adhere to the same scoping rules as variables.

That would be nice behavior.

> However, as it turns out, (at least CMake 3.5.1) this is not the case.
> CMake seems to use the last definition of a function it encounters,
> independent of current scope.

Commands (builtin+functions+macros) are currently scoped globally.

> Now I am wondering if this behaviour is actually intended or if it is a
> corner case which just never surfaced before.

It just happened to be implemented that way from the beginning back in
our wild west days without much thought to scoping.  It is indeed not
documented AFAIK, but a good place to add this to the docs might be here:

 
https://cmake.org/cmake/help/v3.7/manual/cmake-language.7.html#command-definitions

It is also something that could be changed by the introduction of a
new CMake Policy, though it would be a bit of work to get right.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] clang-format

2016-11-14 Thread Tiago Macarios 
Well, I don't really mind how it is implemented. During compilation, or as
a separate target, but it would be a nice feature.

On Sun, Nov 13, 2016 at 11:08 PM, Patrick Boettcher <
patrick.boettc...@posteo.de> wrote:

> Hi,
>
> On Mon, 7 Nov 2016 12:06:15 -0800
> Tiago Macarios  wrote:
> > CMake has "built-in" support for clang_tidy and include-what-you-use.
> > I was wondering why there is not support for clang_format. No one ever
> > contributed, or people think this should not be part of CMake?
>
> First thought which came to my mind when reading your mail was that no
> automatic tool should change (source-)files during compilation which
> are, possibly, opened in an editor.
>
> But, it would, maybe, be nice to have a custom, optional target to run
> it on demand.
>
> If your editor supports it (mine does, even for selected code-lines, \o/
> ) integrate clang-format as source-code-indentation-tool.
>
> regards
> --
> Patrick.
>
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v3.7.0-1139-g27c2222

2016-11-14 Thread Brad King 
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  27cbf0c76a37656eb8a755fbe02e4c6a58e8 (commit)
   via  d608cfb6bf6b93add793c64b40787307be10059a (commit)
  from  aef8218ab7e063d209ef236c3caa9d6cc5ec9dbb (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27cbf0c76a37656eb8a755fbe02e4c6a58e8
commit 27cbf0c76a37656eb8a755fbe02e4c6a58e8
Merge: aef8218 d608cfb
Author: Brad King 
AuthorDate: Mon Nov 14 11:49:15 2016 -0500
Commit: Brad King 
CommitDate: Mon Nov 14 11:49:15 2016 -0500

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-509-gd608cfb

2016-11-14 Thread Brad King 
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  d608cfb6bf6b93add793c64b40787307be10059a (commit)
   via  de7083f3c0bdc9c0af0d35c44afde86aab6d6622 (commit)
  from  4a4be0301bd9c6062738e87892cbe5bd8d900a49 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d608cfb6bf6b93add793c64b40787307be10059a
commit d608cfb6bf6b93add793c64b40787307be10059a
Merge: 4a4be03 de7083f
Author: Brad King 
AuthorDate: Mon Nov 14 11:49:05 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 11:49:05 2016 -0500

Merge topic 'ninja-comment-ComputeLinkCmd'

de7083f3 Ninja: Document why ComputeLinkCmd is structured the way it is.


---

Summary of changes:
 Source/cmNinjaNormalTargetGenerator.cxx |3 +++
 1 file changed, 3 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-1137-gaef8218

2016-11-14 Thread Brad King 
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  aef8218ab7e063d209ef236c3caa9d6cc5ec9dbb (commit)
   via  de7083f3c0bdc9c0af0d35c44afde86aab6d6622 (commit)
  from  3c0ece3d42f9251457ff3358aa2626d99fb32532 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aef8218ab7e063d209ef236c3caa9d6cc5ec9dbb
commit aef8218ab7e063d209ef236c3caa9d6cc5ec9dbb
Merge: 3c0ece3 de7083f
Author: Brad King 
AuthorDate: Mon Nov 14 11:46:48 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 11:46:48 2016 -0500

Merge topic 'ninja-comment-ComputeLinkCmd' into next

de7083f3 Ninja: Document why ComputeLinkCmd is structured the way it is.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de7083f3c0bdc9c0af0d35c44afde86aab6d6622
commit de7083f3c0bdc9c0af0d35c44afde86aab6d6622
Author: Robert Maynard 
AuthorDate: Mon Nov 14 11:39:23 2016 -0500
Commit: Robert Maynard 
CommitDate: Mon Nov 14 11:39:23 2016 -0500

Ninja: Document why ComputeLinkCmd is structured the way it is.

diff --git a/Source/cmNinjaNormalTargetGenerator.cxx 
b/Source/cmNinjaNormalTargetGenerator.cxx
index a23e0ad..3598914 100644
--- a/Source/cmNinjaNormalTargetGenerator.cxx
+++ b/Source/cmNinjaNormalTargetGenerator.cxx
@@ -332,6 +332,9 @@ std::vector 
cmNinjaNormalTargetGenerator::ComputeLinkCmd()
   std::vector linkCmds;
   cmMakefile* mf = this->GetMakefile();
   {
+// If we have a rule variable prefer it. In the case of static libraries
+// this occurs when things like IPO is enabled, and we need to use the
+// CMAKE__CREATE_STATIC_LIBRARY_IPO define instead.
 std::string linkCmdVar = this->GetGeneratorTarget()->GetCreateRuleVariable(
   this->TargetLinkLanguage, this->GetConfigName());
 const char* linkCmd = mf->GetDefinition(linkCmdVar);

---

Summary of changes:
 Source/cmNinjaNormalTargetGenerator.cxx |3 +++
 1 file changed, 3 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-1135-g3c0ece3

2016-11-14 Thread Brad King 
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  3c0ece3d42f9251457ff3358aa2626d99fb32532 (commit)
   via  5f795781b8b2594c17fe6fe4385d0b2b8db97278 (commit)
  from  9b8450a4a95777151048b769a2fd8cd79fd0bd92 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c0ece3d42f9251457ff3358aa2626d99fb32532
commit 3c0ece3d42f9251457ff3358aa2626d99fb32532
Merge: 9b8450a 5f79578
Author: Brad King 
AuthorDate: Mon Nov 14 11:27:30 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 11:27:30 2016 -0500

Merge topic 'ExternalProject-URL-and-UPDATE_DISCONNECTED' into next

5f795781 ExternalProject: Fix UPDATE_DISCONNECTED with URL downloads


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f795781b8b2594c17fe6fe4385d0b2b8db97278
commit 5f795781b8b2594c17fe6fe4385d0b2b8db97278
Author: Brad King 
AuthorDate: Mon Nov 14 10:44:04 2016 -0500
Commit: Brad King 
CommitDate: Mon Nov 14 10:55:34 2016 -0500

ExternalProject: Fix UPDATE_DISCONNECTED with URL downloads

When `UPDATE_DISCONNECTED` is enabled the post-update steps
unconditionally depend on a `skip-update` step instead of `update`.
Make `skip-update` available whenever `UPDATE_DISCONNECTED` is enabled,
whether there is a real update step or not.

Closes: #16428

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 1ba4a8f..b15b3f7 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -2165,12 +2165,12 @@ Update to Mercurial >= 2.1.1.
 ${uses_terminal}
 )
 
-  if(always AND update_disconnected)
+  if(update_disconnected)
 _ep_get_step_stampfile(${name} skip-update skip-update_stamp_file)
 string(REPLACE "Performing" "Skipping" comment "${comment}")
 ExternalProject_Add_Step(${name} skip-update
   COMMENT ${comment}
-  ALWAYS 1
+  ALWAYS ${always}
   EXCLUDE_FROM_MAIN 1
   WORKING_DIRECTORY ${work_dir}
   DEPENDEES download
diff --git a/Tests/ExternalProjectLocal/CMakeLists.txt 
b/Tests/ExternalProjectLocal/CMakeLists.txt
index 17f1630..5b94163 100644
--- a/Tests/ExternalProjectLocal/CMakeLists.txt
+++ b/Tests/ExternalProjectLocal/CMakeLists.txt
@@ -131,6 +131,7 @@ ExternalProject_Add(${proj}
   CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH= -G ${CMAKE_GENERATOR} 

   INSTALL_COMMAND ""
   LOG_BUILD 1
+  UPDATE_DISCONNECTED 1
 )
 set_property(TARGET ${proj} PROPERTY FOLDER "Local/TGZ")
 

---

Summary of changes:
 Modules/ExternalProject.cmake |4 ++--
 Tests/ExternalProjectLocal/CMakeLists.txt |1 +
 2 files changed, 3 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-1133-g9b8450a

2016-11-14 Thread Brad King 
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  9b8450a4a95777151048b769a2fd8cd79fd0bd92 (commit)
   via  516a2cd3604ccebe9d0e74248ded9fb7b07bac71 (commit)
  from  e2ebe9d929c61f16cc0847a53b32b4d4475f8244 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b8450a4a95777151048b769a2fd8cd79fd0bd92
commit 9b8450a4a95777151048b769a2fd8cd79fd0bd92
Merge: e2ebe9d 516a2cd
Author: Brad King 
AuthorDate: Mon Nov 14 11:24:43 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 11:24:43 2016 -0500

Merge topic 'cmake-server-fix-16423' into next

516a2cd3 server-mode: Reset GlobalGenerator before configure


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=516a2cd3604ccebe9d0e74248ded9fb7b07bac71
commit 516a2cd3604ccebe9d0e74248ded9fb7b07bac71
Author: Tobias Hunger 
AuthorDate: Mon Nov 14 16:54:04 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 14 11:06:37 2016 -0500

server-mode: Reset GlobalGenerator before configure

This is what cmake-gui also does to avoid CMake crashing on repeated
attempts to configure it.

Fixes #16423.

diff --git a/Source/cmServerProtocol.cxx b/Source/cmServerProtocol.cxx
index 09b08fe..d35efe0 100644
--- a/Source/cmServerProtocol.cxx
+++ b/Source/cmServerProtocol.cxx
@@ -381,25 +381,9 @@ bool cmServerProtocol1_0::DoActivate(const 
cmServerRequest& request,
 return false;
   }
 
-  const std::string fullGeneratorName =
-cmExternalMakefileProjectGenerator::CreateFullGeneratorName(
-  generator, extraGenerator);
-
-  cm->SetGeneratorToolset(toolset);
-  cm->SetGeneratorPlatform(platform);
-
-  cmGlobalGenerator* gg = cm->CreateGlobalGenerator(fullGeneratorName);
-  if (!gg) {
-setErrorMessage(
-  errorMessage,
-  std::string("Could not set up the requested combination of \"") +
-kGENERATOR_KEY + "\" and \"" + kEXTRA_GENERATOR_KEY + "\"");
-return false;
-  }
-
-  cm->SetGlobalGenerator(gg);
-  cm->SetHomeDirectory(sourceDirectory);
-  cm->SetHomeOutputDirectory(buildDirectory);
+  this->GeneratorInfo =
+GeneratorInformation(generator, extraGenerator, toolset, platform,
+ sourceDirectory, buildDirectory);
 
   this->m_State = STATE_ACTIVE;
   return true;
@@ -931,6 +915,13 @@ cmServerResponse cmServerProtocol1_0::ProcessConfigure(
 
   FileMonitor()->StopMonitoring();
 
+  std::string errorMessage;
+  cmake* cm = this->CMakeInstance();
+  this->GeneratorInfo.SetupGenerator(cm, );
+  if (!errorMessage.empty()) {
+return request.ReportError(errorMessage);
+  }
+
   // Make sure the types of cacheArguments matches (if given):
   std::vector cacheArgs;
   bool cacheArgumentsError = false;
@@ -955,15 +946,13 @@ cmServerResponse cmServerProtocol1_0::ProcessConfigure(
   "cacheArguments must be unset, a string or an array of strings.");
   }
 
-  cmake* cm = this->CMakeInstance();
   std::string sourceDir = cm->GetHomeDirectory();
   const std::string buildDir = cm->GetHomeOutputDirectory();
 
   cmGlobalGenerator* gg = cm->GetGlobalGenerator();
 
   if (buildDir.empty()) {
-return request.ReportError(
-  "No build directory set via setGlobalSettings.");
+return request.ReportError("No build directory set via Handshake.");
   }
 
   if (cm->LoadCache(buildDir)) {
@@ -1038,14 +1027,12 @@ cmServerResponse 
cmServerProtocol1_0::ProcessGlobalSettings(
   obj[kWARN_UNUSED_CLI_KEY] = cm->GetWarnUnusedCli();
   obj[kCHECK_SYSTEM_VARS_KEY] = cm->GetCheckSystemVars();
 
-  obj[kSOURCE_DIRECTORY_KEY] = cm->GetHomeDirectory();
-  obj[kBUILD_DIRECTORY_KEY] = cm->GetHomeOutputDirectory();
+  obj[kSOURCE_DIRECTORY_KEY] = this->GeneratorInfo.SourceDirectory;
+  obj[kBUILD_DIRECTORY_KEY] = this->GeneratorInfo.BuildDirectory;
 
   // Currently used generator:
-  cmGlobalGenerator* gen = cm->GetGlobalGenerator();
-  obj[kGENERATOR_KEY] = gen ? gen->GetName() : std::string();
-  obj[kEXTRA_GENERATOR_KEY] =
-gen ? gen->GetExtraGeneratorName() : std::string();
+  obj[kGENERATOR_KEY] = this->GeneratorInfo.GeneratorName;
+  obj[kEXTRA_GENERATOR_KEY] = this->GeneratorInfo.ExtraGeneratorName;
 
   return request.Reply(obj);
 }
@@ -1109,3 +1096,41 @@ cmServerResponse 
cmServerProtocol1_0::ProcessFileSystemWatchers(
 
   return request.Reply(result);
 }
+
+cmServerProtocol1_0::GeneratorInformation::GeneratorInformation(
+  const std::string& generatorName, const std::string& extraGeneratorName,
+  const std::string& toolset, const std::string& platform,
+  const std::string&

[CMake] Are the current scoping rules for functions intended and documented?

2016-11-14 Thread Mario Werner 
Hi,

I was just surprised by the scoping rules of CMake when it comes to
function definitions and sub scopes (i.e., subdirectories). I expected
that function definitions adhere to the same scoping rules as variables.
More concretely, I assumed that function definitions in a sub scope are
only valid in the same (or deeper) scope(s) but do not influence
definitions in potential parent scopes.

However, as it turns out, (at least CMake 3.5.1) this is not the case.
CMake seems to use the last definition of a function it encounters,
independent of current scope.

I uploaded a quick minimal working example which shows what I mean under
[1]. I just discovered this behaviour by hunting down a bug in our build
system which was caused by the fact that a function definition in a sub
project overwrote an identically named function in the parent project.

Now I am wondering if this behaviour is actually intended or if it is a
corner case which just never surfaced before. The documentation on
functions [2] unfortunately also omits how this is supposed to behave.

Any pointers would be appreciated.

Regards,
Mario

[1] https://github.com/niosHD/mwe-cmake-function-scopes
[2] https://cmake.org/cmake/help/v3.7/command/function.html

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v3.7.0-1131-ge2ebe9d

2016-11-14 Thread Brad King 
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  e2ebe9d929c61f16cc0847a53b32b4d4475f8244 (commit)
   via  d0a707b3d0c247d6bbf63fdfefc79d5ce0aea717 (commit)
  from  7ea9805db8ae5017a26448d65048986ef2d10568 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e2ebe9d929c61f16cc0847a53b32b4d4475f8244
commit e2ebe9d929c61f16cc0847a53b32b4d4475f8244
Merge: 7ea9805 d0a707b
Author: Brad King 
AuthorDate: Mon Nov 14 10:19:50 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 10:19:50 2016 -0500

Merge topic 'cmake-server-fix-16422' into next

d0a707b3 server-mode: Prevent possible crash when watching directories


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0a707b3d0c247d6bbf63fdfefc79d5ce0aea717
commit d0a707b3d0c247d6bbf63fdfefc79d5ce0aea717
Author: Tobias Hunger 
AuthorDate: Mon Nov 14 15:38:05 2016 +0100
Commit: Brad King 
CommitDate: Mon Nov 14 10:18:44 2016 -0500

server-mode: Prevent possible crash when watching directories

The `filename` passed by libuv may be `nullptr`, so handle that
explicitly.

Fixes: #16422

diff --git a/Source/cmFileMonitor.cxx b/Source/cmFileMonitor.cxx
index 41ec8b4..ea37683 100644
--- a/Source/cmFileMonitor.cxx
+++ b/Source/cmFileMonitor.cxx
@@ -288,7 +288,7 @@ void on_directory_change(uv_fs_event_t* handle, const char* 
filename,
 {
   const cmIBaseWatcher* const watcher =
 static_cast(handle->data);
-  const std::string pathSegment(filename);
+  const std::string pathSegment(filename ? filename : "");
   watcher->Trigger(pathSegment, events, status);
 }
 

---

Summary of changes:
 Source/cmFileMonitor.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-1129-g7ea9805

2016-11-14 Thread Brad King 
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  7ea9805db8ae5017a26448d65048986ef2d10568 (commit)
   via  c087072e21823703a0979c2fde3419846f80cc8a (commit)
  from  eb936525a239daceef1fb6c607e540046cf09f92 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ea9805db8ae5017a26448d65048986ef2d10568
commit 7ea9805db8ae5017a26448d65048986ef2d10568
Merge: eb93652 c087072
Author: Brad King 
AuthorDate: Mon Nov 14 10:14:07 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 10:14:07 2016 -0500

Merge topic 'FindBISON-fix-rebuild' into next

c087072e FindBISON: Do not rebuild every time when not VERBOSE


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c087072e21823703a0979c2fde3419846f80cc8a
commit c087072e21823703a0979c2fde3419846f80cc8a
Author: Brad King 
AuthorDate: Mon Nov 14 10:03:15 2016 -0500
Commit: Brad King 
CommitDate: Mon Nov 14 10:06:48 2016 -0500

FindBISON: Do not rebuild every time when not VERBOSE

Since commit v3.7.0-rc1~348^2~3 (FindBISON: Change usage of [VERBOSE
] to [VERBOSE []], 2016-07-16) we always list the VERBOSE
output file as an output of our custom command even if the option is not
used.  This causes the rule to re-run every time (e.g. with Ninja).
Revert one hunk from that change (that looks incorrect) to fix it.

Closes: #16426

diff --git a/Modules/FindBISON.cmake b/Modules/FindBISON.cmake
index 5de7a39..d40b806 100644
--- a/Modules/FindBISON.cmake
+++ b/Modules/FindBISON.cmake
@@ -228,7 +228,7 @@ if(BISON_EXECUTABLE)
   list(APPEND BISON_TARGET_outputs "${BISON_TARGET_output_header}")
 
   add_custom_command(OUTPUT ${BISON_TARGET_outputs}
-${BISON_TARGET_verbose_file}
+${BISON_TARGET_extraoutputs}
 COMMAND ${BISON_EXECUTABLE} ${BISON_TARGET_cmdopt} -o ${BisonOutput} 
${BisonInput}
 VERBATIM
 DEPENDS ${BisonInput}

---

Summary of changes:
 Modules/FindBISON.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET

2016-11-14 Thread Brad King 
On 07/18/2016 09:14 AM, Brad King wrote:
>  FindBISON: Change usage of [VERBOSE ] to [VERBOSE []]
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad2497aa

BTW, this caused a regression reported here:

* https://gitlab.kitware.com/cmake/cmake/issues/16426

Please take a look at the fix here:

* https://gitlab.kitware.com/cmake/cmake/merge_requests/250

Thanks,
-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] FindBoost not finding MinGW libraries

2016-11-14 Thread Sergei Nikulov 
14 ноя 2016 г. 4:36 PM пользователь "David Demelier" <
demelier.da...@gmail.com> написал:
>
> Hello,
>
> I've installed boost under C:\env\mingw64 so I basically have the
> following content:
>
> - C:\env\mingw64\include\boost-1_62\boost\*
> - C:\env\mingw64\lib\libboost_libname-mgw62-1_62.dll(.a)
>
> I've also set the following environment variables:
>
> - BOOST_INCLUDEDIR=C:\env\mingw64\include\boost-1_62
> - BOOST_LIBRARYDIR=C:\env\mingw64\lib
> - BOOST_ROOT=C:\env\mingw64
>
> The following CMakeLists could not find boost:
>
> cmake_minimum_required(VERSION 3.5)
> project(boosttest)
> find_package(Boost REQUIRED COMPONENTS system)
>
> running cmake -G"MinGW Makefiles" -DBoost_DEBUG=On ends with this:
>
> -- The C compiler identification is GNU 6.2.0
> -- The CXX compiler identification is GNU 6.2.0
> -- Check for working C compiler: C:/mingw64/bin/gcc.exe
> -- Check for working C compiler: C:/mingw64/bin/gcc.exe -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: C:/mingw64/bin/g++.exe
> -- Check for working CXX compiler: C:/mingw64/bin/g++.exe -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:946 ]
> _boost_TEST_VERSIONS =
>
1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:948 ]
> Boost_USE_MULTITHREADED = TRUE
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:950 ]
> Boost_USE_STATIC_LIBS =
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:952 ]
> Boost_USE_STATIC_RUNTIME =
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:954 ]
> Boost_ADDITIONAL_VERSIONS =
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:956 ]
> Boost_NO_SYSTEM_PATHS =
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1024 ] Declared as
> CMake or Environmental Variables:
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1026 ]
> BOOST_ROOT =
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1028 ]
> BOOST_INCLUDEDIR =
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1030 ]
> BOOST_LIBRARYDIR =
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1032 ]
> _boost_TEST_VERSIONS =
>
1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1101 ] Include
> debugging info:
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1103 ]
> _boost_INCLUDE_SEARCH_DIRS =
>
C:/env/mingw64/include/boost-1_62;C:/env/mingw64/include;C:/env/mingw64;PATHS;C:/boost/include;C:/boost;/sw/local/include
> -- [ C:/Program
> Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1105 ]
> _boost_PATH_SUFFIXES =
>
boost-1_61_0;boost_1_61_0;boost/boost-1_61_0;boost/boost_1_61_0;boost-1_61;boost_1_61;boost/boost-1_61;boost/boost_1_61;boost-1_60_0;boost_1_60_0;boost/boost-1_60_0;boost/boost_1_60_0;boost-1_60;boost_1_60;boost/boost-1_60;boost/boost_1_60;boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59;boost-1_58_0;boost_1_58_0;boost/boost-1_58_0;boost/boost_1_58_0;boost-1_58;boost_1_58;boost/boost-1_58;boost/boost_1_58;boost-1_57_0;boost_1_57_0;boost/boost-1_57_0;boost/boost_1_57_0;boost-1_57;boost_1_57;boost/boost-1_57;boost/boost_1_57;boost-1_56_0;boost_1_56_0;boost/boost-1_56_0;boost/boost_1_56_0;boost-1_56;boost_1_56;boost/boost-1_56;boost/boost_1_56;boost-1_55_0;boost_1_55_0;boost/boost-1_55_0;boost/boost_1_55_0;boost-1_55;boost_1_55;boost/boost-1_55;boost/boost_1_55;boost-1_54_0;boost_1_54_0;boost/boost-1_54_0;boost/boost_1_54_0;boost-1_54;boost_1_54;boost/boost-1_54;boost/boost_1_54;boost-1_53_0;boost_1_53_0;boost/boost-
>

[Cmake-commits] CMake branch, next, updated. v3.7.0-1127-geb93652

2016-11-14 Thread Brad King 
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  eb936525a239daceef1fb6c607e540046cf09f92 (commit)
   via  f636d1e74a5a9d39d2f25b72b26c3d24813a5565 (commit)
   via  cb5dba8eb12eb75a8e66bf9326bfec22f90fda9a (commit)
   via  a9fa60997a0e6438399e2e6e4a9c02f2935b386a (commit)
   via  b4ffd26fd8750989a8aadd626242c314068ba987 (commit)
   via  60939702e1071385ada5d1082b88763cbd1bab56 (commit)
   via  92f95aede99c76af2ccff09d5b9cc895539332d0 (commit)
   via  c326209fa351ca236778c462bcb0b85f6fa392f7 (commit)
   via  979e8ba6c6c6ed538b1dd9d60d89d863e7c4273c (commit)
   via  7a79f7e3c13d3f1c87db40c3230716dcb79d0df9 (commit)
   via  87584b5e9d4bb3147de4ad2adac2d337be456a62 (commit)
   via  7fcbd47e955d7e318f1f6dd96cc26d6737525c86 (commit)
   via  c50c32a30f434613a0a46b1c7dbb7eb03d29896d (commit)
  from  08580775f0cd1443db623def952be35f9995f18a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb936525a239daceef1fb6c607e540046cf09f92
commit eb936525a239daceef1fb6c607e540046cf09f92
Merge: 0858077 f636d1e
Author: Brad King 
AuthorDate: Mon Nov 14 09:46:05 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 09:46:05 2016 -0500

Merge topic 'add-SHA-3' into next

f636d1e7 Help: Add notes for topic 'add-SHA-3'
cb5dba8e Tests: Add SHA-3 algorithm coverage to CPack checksum test
a9fa6099 ExternalProject: Add support for SHA-3 algorithms
b4ffd26f ExternalData: Add support for SHA-3 algorithms
60939702 file: Add support for SHA-3 algorithms
92f95aed string: Add support for SHA-3 algorithms
c326209f cmCryptoHash: Add support for SHA-3 algorithms
979e8ba6 Help: De-duplicate and spell out supported hash algorithms
7a79f7e3 librhash: Activate SHA-3 implementation
87584b5e Merge branch 'upstream-librhash' into add-SHA-3
7fcbd47e librhash 2016-11-06 (de79828d)
c50c32a3 librhash: Update import script to add SHA-3 implementation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f636d1e74a5a9d39d2f25b72b26c3d24813a5565
commit f636d1e74a5a9d39d2f25b72b26c3d24813a5565
Author: Brad King 
AuthorDate: Thu Nov 10 16:50:53 2016 -0500
Commit: Brad King 
CommitDate: Fri Nov 11 11:46:01 2016 -0500

Help: Add notes for topic 'add-SHA-3'

diff --git a/Help/release/dev/add-SHA-3.rst b/Help/release/dev/add-SHA-3.rst
new file mode 100644
index 000..5743f10
--- /dev/null
+++ b/Help/release/dev/add-SHA-3.rst
@@ -0,0 +1,4 @@
+add-SHA-3
+-
+
+* CMake functionality using cryptographic hashes now supports SHA-3 algorithms.

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cb5dba8eb12eb75a8e66bf9326bfec22f90fda9a
commit cb5dba8eb12eb75a8e66bf9326bfec22f90fda9a
Author: Brad King 
AuthorDate: Thu Nov 10 16:42:34 2016 -0500
Commit: Brad King 
CommitDate: Fri Nov 11 11:46:01 2016 -0500

Tests: Add SHA-3 algorithm coverage to CPack checksum test

diff --git a/Tests/RunCMake/CPack/RunCMakeTest.cmake 
b/Tests/RunCMake/CPack/RunCMakeTest.cmake
index 38bd0ea..61d4332 100644
--- a/Tests/RunCMake/CPack/RunCMakeTest.cmake
+++ b/Tests/RunCMake/CPack/RunCMakeTest.cmake
@@ -22,4 +22,4 @@ run_cpack_test(DEB_GENERATE_SHLIBS_LDCONFIG "DEB" true)
 run_cpack_test(DEBUGINFO "RPM" true)
 run_cpack_test_subtests(SINGLE_DEBUGINFO 
"no_main_component;one_component;one_component_main;no_debuginfo;one_component_no_debuginfo;no_components;valid"
 "RPM" true)
 run_cpack_test(LONG_FILENAMES "DEB" false)
-run_cpack_test_subtests(PACKAGE_CHECKSUM 
"invalid;MD5;SHA1;SHA224;SHA256;SHA384;SHA512" "TGZ" false)
+run_cpack_test_subtests(PACKAGE_CHECKSUM 
"invalid;MD5;SHA1;SHA224;SHA256;SHA384;SHA512;SHA3_224;SHA3_256;SHA3_384;SHA3_512"
 "TGZ" false)

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a9fa60997a0e6438399e2e6e4a9c02f2935b386a
commit a9fa60997a0e6438399e2e6e4a9c02f2935b386a
Author: Brad King 
AuthorDate: Thu Nov 10 16:36:12 2016 -0500
Commit: Brad King 
CommitDate: Fri Nov 11 11:46:00 2016 -0500

ExternalProject: Add support for SHA-3 algorithms

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 1e0be09..88ea4d8 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -423,7 +423,7 @@ if(_ep_func)
 endif()
 
 # Save regex matching supported hash algorithm names.
-set(_ep_hash_algos "MD5|SHA1|SHA224|SHA256|SHA384|SHA512")
+set(_ep_hash_algos

[Cmake-commits] CMake branch, next, updated. v3.7.0-1114-g0858077

2016-11-14 Thread Brad King 
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  08580775f0cd1443db623def952be35f9995f18a (commit)
   via  4a4be0301bd9c6062738e87892cbe5bd8d900a49 (commit)
   via  bfa8831f0219d7c01ff3f434882e2ad941206e96 (commit)
   via  0120e474a3ff3067faabc6c1e370f8b4f0a733d2 (commit)
   via  f02b67787d89ac5b430558d62b74483eaa03c1b8 (commit)
  from  4f83efc02275a14eb47243b9d7ebb47b1e7b5797 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08580775f0cd1443db623def952be35f9995f18a
commit 08580775f0cd1443db623def952be35f9995f18a
Merge: 4f83efc 4a4be03
Author: Brad King 
AuthorDate: Mon Nov 14 09:44:26 2016 -0500
Commit: Brad King 
CommitDate: Mon Nov 14 09:44:26 2016 -0500

Merge branch 'master' into next


---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-507-g4a4be03

2016-11-14 Thread Brad King 
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  4a4be0301bd9c6062738e87892cbe5bd8d900a49 (commit)
   via  a57e76301baf95bc4acf9a1ed50e349220b45579 (commit)
   via  013193d0b00f5a9db5440b2306548b44cbcfc21c (commit)
   via  ec1d585c43b60a8f9c7b3cb1636e831915b37eb0 (commit)
   via  4c5b3c1ceaec319163fa26a8e55eb669f11ee8a5 (commit)
   via  d0a9d8bbe60edfb7cf7569fe8162b17bba294182 (commit)
  from  bfa8831f0219d7c01ff3f434882e2ad941206e96 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4a4be0301bd9c6062738e87892cbe5bd8d900a49
commit 4a4be0301bd9c6062738e87892cbe5bd8d900a49
Merge: bfa8831 a57e763
Author: Brad King 
AuthorDate: Mon Nov 14 09:44:17 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 09:44:17 2016 -0500

Merge topic 'swig_add_library'

a57e7630 Help: Add notes for topic 'swig_add_library'
013193d0 SwigTest: Update for swig_add_library and add lua example
ec1d585c UseSWIG: Do not set PREFIX property for SHARED and STATIC lua 
libraries
4c5b3c1c UseSWIG: Do not set NO_SONAME property for SHARED and STATIC 
libraries
d0a9d8bb UseSWIG: Add swig_add_library macro.


---

Summary of changes:
 Help/release/dev/swig_add_library.rst |8 +
 Modules/UseSWIG.cmake |   56 +++--
 Tests/SwigTest/CMakeLists.txt |   13 ++--
 3 files changed, 66 insertions(+), 11 deletions(-)
 create mode 100644 Help/release/dev/swig_add_library.rst


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-1109-g4f83efc

2016-11-14 Thread Brad King 
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  4f83efc02275a14eb47243b9d7ebb47b1e7b5797 (commit)
   via  2efa764c16f7a0b89e7c688513f98846ffc8bcc7 (commit)
  from  4a90a79f157764c13d1efc3f94ec59212d225bba (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f83efc02275a14eb47243b9d7ebb47b1e7b5797
commit 4f83efc02275a14eb47243b9d7ebb47b1e7b5797
Merge: 4a90a79 2efa764
Author: Brad King 
AuthorDate: Mon Nov 14 09:42:44 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 14 09:42:44 2016 -0500

Merge topic 'childEncoding' into next

2efa764c Revert topic 'childEncoding'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2efa764c16f7a0b89e7c688513f98846ffc8bcc7
commit 2efa764c16f7a0b89e7c688513f98846ffc8bcc7
Author: Brad King 
AuthorDate: Mon Nov 14 09:35:35 2016 -0500
Commit: Brad King 
CommitDate: Mon Nov 14 09:35:35 2016 -0500

Revert topic 'childEncoding'

It causes the CTest.UpdateGIT test to fail on Windows.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index fcda6f9..718b022 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -330,8 +330,6 @@ set(SRCS
   cmOrderDirectories.h
   cmPolicies.h
   cmPolicies.cxx
-  cmProcessOutput.cxx
-  cmProcessOutput.h
   cmProcessTools.cxx
   cmProcessTools.h
   cmProperty.cxx
@@ -634,9 +632,6 @@ set(SRCS
   cm_codecvt.cxx
   )
 
-SET_PROPERTY(SOURCE cmProcessOutput.cxx APPEND PROPERTY COMPILE_DEFINITIONS
-  KWSYS_ENCODING_DEFAULT_CODEPAGE=${KWSYS_ENCODING_DEFAULT_CODEPAGE})
-
 # Kdevelop only works on UNIX and not windows
 if(UNIX)
   set(SRCS ${SRCS} cmGlobalKdevelopGenerator.cxx)
diff --git a/Source/CTest/cmCTestBuildHandler.cxx 
b/Source/CTest/cmCTestBuildHandler.cxx
index a455908..7b4d994 100644
--- a/Source/CTest/cmCTestBuildHandler.cxx
+++ b/Source/CTest/cmCTestBuildHandler.cxx
@@ -7,7 +7,6 @@
 #include "cmFileTimeComparison.h"
 #include "cmGeneratedFileStream.h"
 #include "cmMakefile.h"
-#include "cmProcessOutput.h"
 #include "cmSystemTools.h"
 #include "cmXMLWriter.h"
 
@@ -766,7 +765,7 @@ void cmCTestBuildHandler::LaunchHelper::WriteScrapeMatchers(
 
 int cmCTestBuildHandler::RunMakeCommand(const char* command, int* retVal,
 const char* dir, int timeout,
-std::ostream& ofs, Encoding encoding)
+std::ostream& ofs)
 {
   // First generate the command and arguments
   std::vector args = cmSystemTools::ParseArguments(command);
@@ -810,8 +809,6 @@ int cmCTestBuildHandler::RunMakeCommand(const char* 
command, int* retVal,
 
   char* data;
   int length;
-  cmProcessOutput processOutput(encoding);
-  std::string strdata;
   cmCTestOptionalLog(
 this->CTest, HANDLER_PROGRESS_OUTPUT, "   Each symbol represents "
   << tick_len << " bytes of output." << std::endl
@@ -845,25 +842,13 @@ int cmCTestBuildHandler::RunMakeCommand(const char* 
command, int* retVal,
 
 // Process the chunk of data
 if (res == cmsysProcess_Pipe_STDERR) {
-  processOutput.DecodeText(data, length, strdata, 1);
-  this->ProcessBuffer(strdata.c_str(), strdata.size(), tick, tick_len, ofs,
+  this->ProcessBuffer(data, length, tick, tick_len, ofs,
   >BuildProcessingErrorQueue);
 } else {
-  processOutput.DecodeText(data, length, strdata, 2);
-  this->ProcessBuffer(strdata.c_str(), strdata.size(), tick, tick_len, ofs,
+  this->ProcessBuffer(data, length, tick, tick_len, ofs,
   >BuildProcessingQueue);
 }
   }
-  processOutput.DecodeText(std::string(), strdata, 1);
-  if (!strdata.empty()) {
-this->ProcessBuffer(strdata.c_str(), strdata.size(), tick, tick_len, ofs,
->BuildProcessingErrorQueue);
-  }
-  processOutput.DecodeText(std::string(), strdata, 2);
-  if (!strdata.empty()) {
-this->ProcessBuffer(strdata.c_str(), strdata.size(), tick, tick_len, ofs,
->BuildProcessingQueue);
-  }
 
   this->ProcessBuffer(CM_NULLPTR, 0, tick, tick_len, ofs,
   >BuildProcessingQueue);
@@ -935,7 +920,7 @@ int cmCTestBuildHandler::RunMakeCommand(const char* 
command, int* retVal,
 //##
 //##
 
-void cmCTestBuildHandler::ProcessBuffer(const char* data, size_t length,
+void cmCTestBuildHandler::ProcessBuffer(const char* data, int

[CMake] FindBoost not finding MinGW libraries

2016-11-14 Thread David Demelier 
Hello,

I've installed boost under C:\env\mingw64 so I basically have the
following content:

- C:\env\mingw64\include\boost-1_62\boost\*
- C:\env\mingw64\lib\libboost_libname-mgw62-1_62.dll(.a)

I've also set the following environment variables:

- BOOST_INCLUDEDIR=C:\env\mingw64\include\boost-1_62
- BOOST_LIBRARYDIR=C:\env\mingw64\lib
- BOOST_ROOT=C:\env\mingw64

The following CMakeLists could not find boost:

cmake_minimum_required(VERSION 3.5)
project(boosttest)
find_package(Boost REQUIRED COMPONENTS system)

running cmake -G"MinGW Makefiles" -DBoost_DEBUG=On ends with this:

-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- Check for working C compiler: C:/mingw64/bin/gcc.exe
-- Check for working C compiler: C:/mingw64/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/mingw64/bin/g++.exe
-- Check for working CXX compiler: C:/mingw64/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:946 ]
_boost_TEST_VERSIONS =
1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:948 ]
Boost_USE_MULTITHREADED = TRUE
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:950 ]
Boost_USE_STATIC_LIBS =
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:952 ]
Boost_USE_STATIC_RUNTIME =
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:954 ]
Boost_ADDITIONAL_VERSIONS =
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:956 ]
Boost_NO_SYSTEM_PATHS =
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1024 ] Declared as
CMake or Environmental Variables:
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1026 ]
BOOST_ROOT =
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1028 ]
BOOST_INCLUDEDIR =
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1030 ]
BOOST_LIBRARYDIR =
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1032 ]
_boost_TEST_VERSIONS =
1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1101 ] Include
debugging info:
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1103 ]
_boost_INCLUDE_SEARCH_DIRS =
C:/env/mingw64/include/boost-1_62;C:/env/mingw64/include;C:/env/mingw64;PATHS;C:/boost/include;C:/boost;/sw/local/include
-- [ C:/Program
Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1105 ]
_boost_PATH_SUFFIXES =
boost-1_61_0;boost_1_61_0;boost/boost-1_61_0;boost/boost_1_61_0;boost-1_61;boost_1_61;boost/boost-1_61;boost/boost_1_61;boost-1_60_0;boost_1_60_0;boost/boost-1_60_0;boost/boost_1_60_0;boost-1_60;boost_1_60;boost/boost-1_60;boost/boost_1_60;boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59;boost-1_58_0;boost_1_58_0;boost/boost-1_58_0;boost/boost_1_58_0;boost-1_58;boost_1_58;boost/boost-1_58;boost/boost_1_58;boost-1_57_0;boost_1_57_0;boost/boost-1_57_0;boost/boost_1_57_0;boost-1_57;boost_1_57;boost/boost-1_57;boost/boost_1_57;boost-1_56_0;boost_1_56_0;boost/boost-1_56_0;boost/boost_1_56_0;boost-1_56;boost_1_56;boost/boost-1_56;boost/boost_1_56;boost-1_55_0;boost_1_55_0;boost/boost-1_55_0;boost/boost_1_55_0;boost-1_55;boost_1_55;boost/boost-1_55;boost/boost_1_55;boost-1_54_0;boost_1_54_0;boost/boost-1_54_0;boost/boost_1_54_0;boost-1_54;boost_1_54;boost/boost-1_54;boost/boost_1_54;boost-1_53_0;boost_1_53_0;boost/boost-

Re: [cmake-developers] Current deficiencies of automoc

2016-11-14 Thread Sebastian Holtermann 
Am 14.11.2016 um 12:41 schrieb Alan W. Irwin:
> On 2016-11-14 09:06+0100 Sebastian Holtermann wrote:
> 
>> What probably could be done is to add
>> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
>> to the INCLUDE_DIRECTORIES of the target and then generate all
>> #included moc file there, accepting the risk of intra target name
>> collisions.
> 
> Hi Sebastian:
> 
> Your compromise idea above sounds good to me!
> 

Btw. I liked your
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
${HEADERPATHCHECKSUM}/
moc_${HEADERNAME}.cpp
approach.

It could be used for the moc_.cpp files that are not
manually #included and therefore can have any name.

Over the current
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
moc_${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
scheme it has the advantages that
1) moc_.cpp files are grouped by their source directory
2) ${HEADERNAME} is kept intact and does not get shortened
3) fewer weird looking checksum names ;)

1) and 2) are generally helpful to find and debug moced files I think.

There are a some other changes to the automoc system I would like to
propose / work on. I'm currently busy with an other project though.

-Sebastian


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Current deficiencies of automoc

2016-11-14 Thread Alan W. Irwin 

On 2016-11-14 09:06+0100 Sebastian Holtermann wrote:


What probably could be done is to add
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
to the INCLUDE_DIRECTORIES of the target and then generate all
#included moc file there, accepting the risk of intra target name
collisions.


Hi Sebastian:

Your compromise idea above sounds good to me!

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] CMake 3.7: Test #379: RunCMake.CPack_RPM fails

2016-11-14 Thread Domen Vrankar 
2016-11-12 14:38 GMT+01:00 Christoph Grüninger :

> Dear CMake folks,
> I am trying to package CMake for openSuse. I was a bit surprised that
> the new dependency libuv was nowhere mentioned. Can it be disabled by a
> configure switch for older systems?
>

If I remember correctly libuv is only used for cmake server mode so if you
don't want libuv dependency you just loose that optional functionality but
this would probably be better to ask in a separate mail as I'm not certain
how many people will look into CPack/RPM specific mail.


> CMake 3.7 compiles so far, but test #379 (RunCMake.CPack_RPM) fails, see
> the error below from OBS. I had a brief look at our patches and I am apt
> to think they are unrelated.
> Can someone have a look and give some hint?
>

I'll test it today in the afternoon but for now since sources are missing
from the package I'm guessing that debuginfo rpm packaging rpmbuild macro
on openSUSE has some differences compared to the one in other distros.
CPack/RPM overrides it to compensate for the fact that sources can be
generated during build (rpmbuild debuginfo macro only supports packaging of
sources located in source dir during packaging so that works only for
insource builds...).

Regards,
Domen
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] Current deficiencies of automoc

2016-11-14 Thread Sebastian Holtermann 
Am 13.11.2016 um 07:48 schrieb Alan W. Irwin:
> On 2016-10-22 19:49+0200 Sebastian Holtermann wrote:
> 
> [...]
>> Actually I made an implementation in 3.6.0 that generated the moc files
>> in the a build tree subdirectory correspoding to the header path.
>> But that blew up on some projects because the generated paths got too
>> long for some compiĺers. That implementation was theefore reverted.
>> In 3.7  there is a new approatch that generates the moc files in
>> ${CMAKE_BINARY_DIR}/
>>${TARGETNAME}_automoc.dir/
>>${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
>> This ensures that the paths don't get too long and that there won't be
>> any name collisions.
> 
> Hi Sebastian:
> 
> After a substantial break to finish off a different project, I have
> now had a chance to return to the present topic using my attached
> test_automoc project.  (Also available in the cmake/test_automoc
> subdirectory of the PLplot git master branch that can be accessed at
> .) The
> project builds 6 separate simple Qt5 applications that #include a
> header that needs moc processing.  The only differences between the
> source code files for the various executables is the name and
> directory location of that #include'd file and the various instructions
> given to automoc (and in one case qt5_wrap_cpp) to process that file.
> 
> With that test project, I now confirm (sorry about the noise to the
> contrary before) that automoc does use the approach you mentioned
> above for CMake-3.7.0 to reduce the name collisions that occur for
> that same project for earlier versions of CMake.
> 
> Concerning the collisions still expected for 3.7.0, the automoc
> documentation (see
> ) states the
> following:
> 
> "However, if multiple source files in different directories do this
> [i.e., contain an "#include "moc_.cpp" when the header
> name is .h] then their generated moc files would
> collide. In this case a diagnostic will be issued."
> 
> For the life of me, I cannot find a way to generate that diagnostic.
> Instead, three different targets (two targets concerning the same
> implementation code and header in the same directory and a third
> target for a copy of that same implementation code and header in a
> different directory) generate at build time a file named
> moc_test_q_object.cpp in the same build directory at different times.
> This is a clear example of a three-way name collision, but CMake does
> not issue a diagnostic for any of these targets concerning that
> collision contrary to the above documentation.
> 
> Could you please take a look at the three last executables configured
> for this test case (helloworld_automoc_same_include,
> helloworld_automoc_same_include1, and
> helloworld_automoc_same_include2) to see why that collision diagnostic
> is not being issued with cmake-3.7.0?  Better yet, of course, would be
> to solve these remaining name collisions completely by using a
> modification of your idea above, i.e., for this special case where
> users implementation code contained
> 
> #include "moc_.cpp"
> 
> then moc should generate the file
> 
> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM}/moc_${HEADERNAME}.cpp
> 
> 
> Note, the generated moc file has the name expected by the #include so
> I believe this idea would work so long as automoc automatically
> appended
> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM} to
> the target INCLUDE_DIRECTORIES property.
> 

Hi Alan,

the automoc diagnostic checks for name collisions within a single target
only, not across multiple targets - as in your example.

The problem I see is that all moc files included by the
#include "moc_.cpp"
scheme get generated in ${CMAKE_BINARY_DIR}.
It would be better to generate them in
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
to avoid inter target name collisions.
Your solution using the path checksum as well would be event better
as it avoids name collisions even within a target.
The problem there is though that it would require to add
a .cpp file specific -I compiler statement for every .cpp file
that includes a moc file.
This is hard to do with the current automoc implementation.
I would not want to do it.
What probably could be done is to add
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
to the INCLUDE_DIRECTORIES of the target and then generate all
#included moc file there, accepting the risk of intra target name
collisions.

-Sebastian

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other