[Cmake-commits] CMake branch, master, updated. v3.10.0-499-gbfbe4aa

[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  bfbe4aaeb8d31676960175d07d6f412277d8cd9d (commit)
  from  a4faf8638744edf7e3dd8931b55ba87e8f7738be (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=bfbe4aaeb8d31676960175d07d6f412277d8cd9d
commit bfbe4aaeb8d31676960175d07d6f412277d8cd9d
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sat Dec 2 00:03:10 2017 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sat Dec 2 00:03:10 2017 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 305aa87..9a95bba 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 10)
-set(CMake_VERSION_PATCH 20171201)
+set(CMake_VERSION_PATCH 20171202)
 #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] Which targets are affected by CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE?

[Sebastian via CMake]

Hi,

The documentation 
https://cmake.org/cmake/help/v3.10/variable/CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE.html
states "CMake automatically adds for each ... target".

I assume the variable has directory scope. So it affects all targets in that 
directory? Or only targets which are created (by add_library, for example) 
AFTER setting the variable?
In other words: Which commands evaluates the variable? add_library? 
target_include_directories?

The documentation could be a bit more clear on this...

Thanks,
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

Re: [CMake] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-12-01 18:04 GMT+01:00 Domen Vrankar :

> 2017-12-01 16:47 GMT+01:00 DKLind :
>
>> This is precisely my situation. I have a large project where 50+ packages
>> are
>> generated. I wanted, needed, to be able to set each packages' version
>> uniquely. Using the CPACK_DEBAIN__PACKAGE_VERSION variable
>> seemed
>> to be the correct way, except it doesn't work. My patch allows
>> CPACK_DEBAIN__PACKAGE_VERSION to be recognized by CPack and
>> it's
>> value used when the package is created. The patch doesn't break the
>> existing
>> functionality of CPACK_PACKAGE_VERSION being used. It simply checks to see
>> of CPACK_DEBAIN__PACKAGE_VERSION is set. If it is, use it's
>> value. It isn't not set use the value of CPACK_PACKAGE_VERSION.
>>
>
> This is exactly what I've described in the reply to Craig. If projects are
> related they should have the same version and release notes and if they
> aren't and are instead just depending on each other (your case) they should
> have a different package name with its own sub-packages, release notes and
> versions. Simply changing the version and release notes but still
> containing one base package name is confusing, hard to maintain and in my
> opinion abusal of sub-packages as the Linux distros that use Rpm and Deb
> packages know them.
>
> This is a case where ExternalProject would be a valid choice but I'm
> guessing that you decided against it as it causes issues when the projects
> are still interdependent enough to warrant extension of functionality on
> all (some) of them at the same time. This was the case on one of the
> projects on which I've worked for a few years now where you have a core and
> different modules that are installed at different clients but not all at
> once (e.g. client one has modules 1, 2 and 3 while client two has 1, 3, 4
> and 5). For such a project you can put everything into one project and
> write "make install" which sets up your entire development environment
> where you can test all the modules interacting with each other and make
> improvements on them.
>
> So my patch adds an alternative to ExternalProject for such cases but
> still packages all of the projects as if they were stand alone projects - a
> superbuild.
>

Craig, David the usual (expected) way of packaging things is (per package
group versioning - currently supported and what my MR enables):

product_1-component_1-1.0.0
product_1-component_2-1.0.0
product_2-component_1-3.5.7
product_2-component_2-3.5.7

And what you are suggesting is (per component versioning):

distro_or_company-product_1-1.0.0
distro_or_company-product_2-3.5.7

On the product where I worked the compromise was to package:

product-component_1_1-1.0.0_3.5.7
product-component_1_2-1.0.0_3.5.7
product-component_2_1-1.0.0_3.5.7
product-component_2_2-1.0.0_3.5.7

Which I would say that it's a bad solution but it gave us what we needed -
group of products that can be built and tested together without a
combination of ExternalProject commands and a build_all.sh script, have
components but their versions increase independently.

The first option is supported by the intuitive use of Linux distributions
by simply running something like "sudo apt search libboost" but it's
possible that the alternative way of packaging is possibly also feasible
for others (and what we did is simply an ugly compromise hack when you need
to hurry and don't want to extend CPack).

Given all of this and if both my proposal and the alternative would be
already implemented in CMake/CPack would you be using the alternative
version from time to time or not?

The alternative would be from my point of view confusing and would probably
add additional custom CPack variable per-component override requirements
but if you think that it would be useful or if my MR is too far off from
where CMake should be going it would still be feasible to implement the per
component version/release notes override.

What do you think?

Thanks,
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] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-12-01 16:47 GMT+01:00 DKLind :

> This is precisely my situation. I have a large project where 50+ packages
> are
> generated. I wanted, needed, to be able to set each packages' version
> uniquely. Using the CPACK_DEBAIN__PACKAGE_VERSION variable
> seemed
> to be the correct way, except it doesn't work. My patch allows
> CPACK_DEBAIN__PACKAGE_VERSION to be recognized by CPack and
> it's
> value used when the package is created. The patch doesn't break the
> existing
> functionality of CPACK_PACKAGE_VERSION being used. It simply checks to see
> of CPACK_DEBAIN__PACKAGE_VERSION is set. If it is, use it's
> value. It isn't not set use the value of CPACK_PACKAGE_VERSION.
>

This is exactly what I've described in the reply to Craig. If projects are
related they should have the same version and release notes and if they
aren't and are instead just depending on each other (your case) they should
have a different package name with its own sub-packages, release notes and
versions. Simply changing the version and release notes but still
containing one base package name is confusing, hard to maintain and in my
opinion abusal of sub-packages as the Linux distros that use Rpm and Deb
packages know them.

This is a case where ExternalProject would be a valid choice but I'm
guessing that you decided against it as it causes issues when the projects
are still interdependent enough to warrant extension of functionality on
all (some) of them at the same time. This was the case on one of the
projects on which I've worked for a few years now where you have a core and
different modules that are installed at different clients but not all at
once (e.g. client one has modules 1, 2 and 3 while client two has 1, 3, 4
and 5). For such a project you can put everything into one project and
write "make install" which sets up your entire development environment
where you can test all the modules interacting with each other and make
improvements on them.

So my patch adds an alternative to ExternalProject for such cases but still
packages all of the projects as if they were stand alone projects - a
superbuild.

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] CPack: Create debian packge for each sub-project

[Domen Vrankar]

2017-12-01 5:41 GMT+01:00 Craig Scott :

>
>
> On Fri, Dec 1, 2017 at 11:15 AM, Domen Vrankar 
> wrote:
>
>> 2017-11-29 17:07 GMT+01:00 DKLind :
>>
>>> I have finally found time to work on a patch so
>>> CPACK_DEBAIN__PACKAGE_VERSION is recognized. I am amazed how
>>> simple the fix actually is.
>>>
>>> I plan on submitting a formal patch soon for Debian and RPM. I don't know
>>> anything about other CMake packaging features that might benefit from
>>> this
>>> patch.
>>>
>>
>> Hi,
>>
>> I've also been working on a bit larger feature extension that would
>> possibly be of interest to you: https://gitlab.kitware.com/cma
>> ke/cmake/merge_requests/1545
>>
>> I haven't decided on implementing per component versioning since it makes
>> no sense to version different components of the same release differently
>> unless they are a separate project which requires more variable overrides
>> and manual setting of components - ExternalProject seems a better
>> alternative in such cases. Maybe your solution can convince me otherwise.
>>
>
> An example where per-component versions would be really useful is if you
> have one large build that produces multiple products (i.e. one git repo and
> one CMake build). You may want to be able to create a release package for
> each product, but if each product has its own distinct version number, then
> you currently can't quite do it with CMake for some package types. I have
> exactly this situation at work at the moment. In one project, I get away
> with it because the release packages are tar balls so I just provide a
> custom name that embeds the version number for each product using
> CPACK_ARCHIVE__FILE_NAME. But I have other projects which
> produce RPMs and for those I don't currently have a solution.
>

The thing is that components are one package split into sub-packages which
are still connected under the same base package name so they should be of
the same version (e.g. I'd be surprised to download Boost rpm packages that
have different version for each component [filesystem, ASIO, Spirit, ...]
and still claim to be the same package group/release).

In super/uber build multiple projects require multiple packages of which
each can have sub-package components and in this case it is logical that
each project has its own package name, version, release notes, debug
package(s) etc.

This is what I'm trying to address with my MR that is work in progress for
now and since it requires changes not just to CPack but also CMake I've
pushed before I invest the time to write all the tests to see what other
people think about it.

As DKLind already found out the addition of per component overrides for
CPack Deb and RPM is trivial but for the past two years I've had the
(possibly misguided) opinion that the first/trivial solution is the wrong
one.

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] CPack: Create debian packge for each sub-project

[DKLind]

This is precisely my situation. I have a large project where 50+ packages are
generated. I wanted, needed, to be able to set each packages' version
uniquely. Using the CPACK_DEBAIN__PACKAGE_VERSION variable seemed
to be the correct way, except it doesn't work. My patch allows
CPACK_DEBAIN__PACKAGE_VERSION to be recognized by CPack and it's
value used when the package is created. The patch doesn't break the existing
functionality of CPACK_PACKAGE_VERSION being used. It simply checks to see
of CPACK_DEBAIN__PACKAGE_VERSION is set. If it is, use it's
value. It isn't not set use the value of CPACK_PACKAGE_VERSION.



--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

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, release, updated. v3.10.0-8-g085bdf5

[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, release has been updated
   via  085bdf5aad5c9b0da2c5b3a831a3276b68535be0 (commit)
   via  375eca7881bceabf591a4fc278c198657aafbd5e (commit)
  from  79ad921a38190e38d10c89f9c7dad1fc78b52986 (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 -
---

Summary of changes:
 bootstrap |1 +
 1 file changed, 1 insertion(+)


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.10.0-498-ga4faf86

[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  a4faf8638744edf7e3dd8931b55ba87e8f7738be (commit)
   via  085bdf5aad5c9b0da2c5b3a831a3276b68535be0 (commit)
  from  a13cc4d7028f7240ce4ff4c5f43e90ef8f61bba0 (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=a4faf8638744edf7e3dd8931b55ba87e8f7738be
commit a4faf8638744edf7e3dd8931b55ba87e8f7738be
Merge: a13cc4d 085bdf5
Author: Brad King 
AuthorDate: Fri Dec 1 08:48:59 2017 -0500
Commit: Brad King 
CommitDate: Fri Dec 1 08:48:59 2017 -0500

Merge branch 'release-3.10'


---

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.10.0-496-ga13cc4d

[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  a13cc4d7028f7240ce4ff4c5f43e90ef8f61bba0 (commit)
   via  5cb64508a3c2c17f3a8c798d60ad426e286cf39e (commit)
   via  f223a7caf494949c241133b7a7a1408738d6b376 (commit)
   via  cbd37fbec37b7fdd05925c46f2d252ad368ebe76 (commit)
  from  22e67bc6bb138d1fb09555f1fdeaaba14312d3da (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=a13cc4d7028f7240ce4ff4c5f43e90ef8f61bba0
commit a13cc4d7028f7240ce4ff4c5f43e90ef8f61bba0
Merge: 22e67bc 5cb6450
Author: Brad King 
AuthorDate: Fri Dec 1 13:26:31 2017 +
Commit: Kitware Robot 
CommitDate: Fri Dec 1 08:26:34 2017 -0500

Merge topic 'update-gitsetup'

5cb64508 Merge branch 'upstream-GitSetup' into update-gitsetup
f223a7ca GitSetup 2017-10-26 (1639317d)
cbd37fbe GitSetup: Restrict import to files we need

Acked-by: Kitware Robot 
Acked-by: Ben Boeckel 
Merge-request: !1543


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5cb64508a3c2c17f3a8c798d60ad426e286cf39e
commit 5cb64508a3c2c17f3a8c798d60ad426e286cf39e
Merge: cbd37fb f223a7c
Author: Brad King 
AuthorDate: Thu Nov 30 14:55:34 2017 -0500
Commit: Brad King 
CommitDate: Thu Nov 30 14:55:34 2017 -0500

Merge branch 'upstream-GitSetup' into update-gitsetup

* upstream-GitSetup:
  GitSetup 2017-10-26 (1639317d)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f223a7caf494949c241133b7a7a1408738d6b376
commit f223a7caf494949c241133b7a7a1408738d6b376
Author: GitSetup Upstream 
AuthorDate: Thu Oct 26 11:31:16 2017 -0400
Commit: Brad King 
CommitDate: Thu Nov 30 14:55:33 2017 -0500

GitSetup 2017-10-26 (1639317d)

Code extracted from:

https://gitlab.kitware.com/utils/gitsetup.git

at commit 1639317d0774f7729118138e978ca6eec9cf984e (setup).

diff --git a/config.sample b/config.sample
deleted file mode 100644
index eeb468b..000
--- a/config.sample
+++ /dev/null
@@ -1,32 +0,0 @@
-# Kitware Local Git Setup Scripts - Sample Project Configuration
-#
-# Copy to "config" and edit as necessary.
-
-[hooks]
-   url = http://public.kitware.com/GitSetup.git
-   #branch = hooks
-
-[ssh]
-   host = public.kitware.com
-   key = id_git_public
-   request-url = https://www.kitware.com/Admin/SendPassword.cgi
-
-[stage]
-   #url = git://public.kitware.com/stage/Project.git
-   #pushurl = g...@public.kitware.com:stage/Project.git
-
-[gerrit]
-   #project = Project
-   site = http://review.source.kitware.com
-   # pushurl placeholder "$username" is literal
-   pushurl = $usern...@review.source.kitware.com:Project
-
-[upstream]
-   url = git://public.kitware.com/Project.git
-
-[gitlab]
-   host = gitlab.kitware.com
-   group-path = group
-   group-name = Group
-   project-path = project
-   project-name = Project
diff --git a/git-gerrit-push b/git-gerrit-push
deleted file mode 100755
index b46f753..000
--- a/git-gerrit-push
+++ /dev/null
@@ -1,74 +0,0 @@
-#!/usr/bin/env bash
-#=
-# Copyright 2010-2015 Kitware, Inc.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-#=
-
-USAGE="[] [--no-topic] [--dry-run] [--]"
-OPTIONS_SPEC=
-SUBDIRECTORY_OK=Yes
-. "$(git --exec-path)/git-sh-setup"
-
-#-
-
-remote=''
-refspecs=''
-no_topic=''
-dry_run=''
-
-# Parse the command line options.
-while test $# != 0; do
-   case "$1" in
-   --no-topic) no_topic=1 ;;
-   --dry-run)  dry_run=--dry-run ;;
-   --) shift; break ;;
-   -*) usage ;;
-   *) test -z "$remote" || usage ; remote="$1" ;;
-   esac
-   shift
-done
-test $# = 0 || usage
-
-# Default 

[Cmake-commits] CMake branch, master, updated. v3.10.0-492-g22e67bc

[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  22e67bc6bb138d1fb09555f1fdeaaba14312d3da (commit)
   via  e61c1cf64c4f39b00e0f8ed81466e85c773d9ba2 (commit)
   via  47c326c36bff1669f17ea2d89c49dc9152f8268a (commit)
   via  3c6dab8b72c1a0736a5ddb4c470cf7b7b544ceb1 (commit)
   via  375eca7881bceabf591a4fc278c198657aafbd5e (commit)
   via  3bcaa870078d875b65f17d82661a133f6d5cbdfc (commit)
   via  dd700e9bfb2a498632845e76ce95dd38bb866a7b (commit)
   via  8112059ee7f38f0eb5cdcaba8185aec659abcbfc (commit)
   via  32cfa7b324de799eefb2f7370fb54b700d1a87a5 (commit)
   via  9af5f6727716ab8b9b61815ec67e1c4ffe1213b6 (commit)
   via  b0e2f1415e680337f4b70b19e319efeba0eb6f12 (commit)
   via  85457b63c859f238ef324757f1042cc846cedbc7 (commit)
  from  006a4956a296ed5a9c01fbd5c242c240dc3aac99 (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=22e67bc6bb138d1fb09555f1fdeaaba14312d3da
commit 22e67bc6bb138d1fb09555f1fdeaaba14312d3da
Merge: e61c1cf 8112059
Author: Brad King 
AuthorDate: Fri Dec 1 13:24:05 2017 +
Commit: Kitware Robot 
CommitDate: Fri Dec 1 08:24:08 2017 -0500

Merge topic 'simplify_target_link_libraries'

8112059e target_link_libraries: Simplify implementation and add comments.
b0e2f141 target_link_libraries: Slightly fix some error-messages.
85457b63 target_link_libraries: Return earlier on some error.

Acked-by: Kitware Robot 
Merge-request: !1531


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e61c1cf64c4f39b00e0f8ed81466e85c773d9ba2
commit e61c1cf64c4f39b00e0f8ed81466e85c773d9ba2
Merge: 47c326c 3bcaa87
Author: Brad King 
AuthorDate: Fri Dec 1 13:22:43 2017 +
Commit: Kitware Robot 
CommitDate: Fri Dec 1 08:22:49 2017 -0500

Merge topic 'libuv-raii'

3bcaa870 cmUVHandlePtr: Add uv_process_ptr
dd700e9b cmUVHandlePtr: Add uv_timer_ptr
32cfa7b3 cmUVHandlePtr: Move to CMakeLib to make it available everywhere

Acked-by: Kitware Robot 
Merge-request: !1541


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=47c326c36bff1669f17ea2d89c49dc9152f8268a
commit 47c326c36bff1669f17ea2d89c49dc9152f8268a
Merge: 3c6dab8 375eca7
Author: Brad King 
AuthorDate: Fri Dec 1 13:18:08 2017 +
Commit: Kitware Robot 
CommitDate: Fri Dec 1 08:18:12 2017 -0500

Merge topic 'bootstrap-clang-5'

375eca78 bootstrap: Check support for unordered_map from compiler mode

Acked-by: Kitware Robot 
Merge-request: !1542


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c6dab8b72c1a0736a5ddb4c470cf7b7b544ceb1
commit 3c6dab8b72c1a0736a5ddb4c470cf7b7b544ceb1
Merge: 006a495 9af5f67
Author: Brad King 
AuthorDate: Fri Dec 1 13:15:40 2017 +
Commit: Kitware Robot 
CommitDate: Fri Dec 1 08:15:51 2017 -0500

Merge topic 'fix-cmake-server-bad-buffering-test'

9af5f672 test: Updated server test harness to try to cause fragmentation

Acked-by: Kitware Robot 
Merge-request: !1508


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=375eca7881bceabf591a4fc278c198657aafbd5e
commit 375eca7881bceabf591a4fc278c198657aafbd5e
Author: Adam Ciarciński 
AuthorDate: Thu Nov 30 13:57:12 2017 -0500
Commit: Brad King 
CommitDate: Thu Nov 30 14:01:26 2017 -0500

bootstrap: Check support for unordered_map from compiler mode

Some versions of clang 5 (with libc++) have a problem with
`unordered_map` under `-std=gnu++1z`:

/usr/include/c++/__hash_table:1134:43: error: conflicting types for 
'__hash_table<_Tp, _Hash, _Equal, _Alloc>'

Include `unordered_map` in our test source so that we reject this
combination and fall back to an older C++ standard flag.

Fixes: #17526

diff --git a/bootstrap b/bootstrap
index 47f7e76..6da87e7 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1056,6 +1056,7 @@ TMPFILE=`cmake_tmp_file`
 echo '
 #include 
 #include 
+#include 
 
 #if __cplusplus < 201103L
 #error "Compiler is not in a mode aware of C++11."

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3bcaa870078d875b65f17d82661a133f6d5cbdfc
commit 3bcaa870078d875b65f17d82661a133f6d5cbdfc
Author: Brad King 
AuthorDate: Thu Nov 30 11:26:25 2017 -0500
Commit: Brad King 
CommitDate: 

[Cmake-commits] CMake branch, master, updated. v3.10.0-480-g006a495

[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  006a4956a296ed5a9c01fbd5c242c240dc3aac99 (commit)
   via  4a3c19a5835de0049cdb2acea7be8ffeaff08aba (commit)
  from  4d0bcc94c4b965dc08f826d2242248fa3db885b7 (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=006a4956a296ed5a9c01fbd5c242c240dc3aac99
commit 006a4956a296ed5a9c01fbd5c242c240dc3aac99
Merge: 4d0bcc9 4a3c19a
Author: Brad King 
AuthorDate: Fri Dec 1 13:11:01 2017 +
Commit: Kitware Robot 
CommitDate: Fri Dec 1 08:11:07 2017 -0500

Merge topic 'fixCMakeVersionRC'

4a3c19a5 Windows: Fix version embedding in CMake binaries

Acked-by: Kitware Robot 
Merge-request: !1536


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4a3c19a5835de0049cdb2acea7be8ffeaff08aba
commit 4a3c19a5835de0049cdb2acea7be8ffeaff08aba
Author: Justin Goshi 
AuthorDate: Wed Nov 29 12:48:26 2017 -0800
Commit: Brad King 
CommitDate: Thu Nov 30 10:42:26 2017 -0500

Windows: Fix version embedding in CMake binaries

In commit 5b9da05b7a (Windows: Embed version information into CMake
binaries, 2017-10-25) we left out `` since MinGW does not have
the header, but it is needed for the `VS_VERSION_INFO` macro.  Provide
the macro ourselves.

Suggested-by: Christian Pfeiffer 

diff --git a/Source/CMakeVersion.rc.in b/Source/CMakeVersion.rc.in
index f4ca3d5..60e14e5 100644
--- a/Source/CMakeVersion.rc.in
+++ b/Source/CMakeVersion.rc.in
@@ -7,6 +7,9 @@
 #define VER_PRODUCTVERSION  
@CMake_VERSION_MAJOR@,@CMake_VERSION_MINOR@,@CMake_VERSION_PATCH@
 #define VER_PRODUCTVERSION_STR  "@CMake_VERSION@\0"
 
+/* Version-information resource identifier.  */
+#define VS_VERSION_INFO 1
+
 VS_VERSION_INFO VERSIONINFO
 FILEVERSIONVER_FILEVERSION
 PRODUCTVERSION VER_PRODUCTVERSION

---

Summary of changes:
 Source/CMakeVersion.rc.in |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, master, updated. v3.10.0-478-g4d0bcc9

[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  4d0bcc94c4b965dc08f826d2242248fa3db885b7 (commit)
   via  340fae777a45c318cf71cd0fbd51bf30194761f2 (commit)
   via  b2f612a0fabfb87e79b60f440c05a2cecde424f0 (commit)
   via  d094b6796a3d9ee91a00f9541416e5d1e9304da8 (commit)
   via  5fa414594eb4c1ca9e7041eb443d503ff495d90d (commit)
   via  a3e029effd84dc185a9cc12e9b4efd48c70dffa6 (commit)
  from  6287365ab090078be306b3199f2e42d8e423311f (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=4d0bcc94c4b965dc08f826d2242248fa3db885b7
commit 4d0bcc94c4b965dc08f826d2242248fa3db885b7
Merge: 340fae7 b2f612a
Author: Brad King 
AuthorDate: Fri Dec 1 13:04:17 2017 +
Commit: Kitware Robot 
CommitDate: Fri Dec 1 08:04:21 2017 -0500

Merge topic 'simplify-fallthrough'

b2f612a0 Simplify CM_FALLTHROUGH implementation

Acked-by: Kitware Robot 
Merge-request: !1540


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=340fae777a45c318cf71cd0fbd51bf30194761f2
commit 340fae777a45c318cf71cd0fbd51bf30194761f2
Merge: 6287365 d094b67
Author: Brad King 
AuthorDate: Fri Dec 1 13:03:46 2017 +
Commit: Kitware Robot 
CommitDate: Fri Dec 1 08:03:53 2017 -0500

Merge topic 'update-kwsys'

d094b679 Merge branch 'upstream-KWSys' into update-kwsys
5fa41459 KWSys 2017-11-30 (fa1ab7b8)
a3e029ef cmStandardLexer.h: Do not include a C++ header

Acked-by: Kitware Robot 
Merge-request: !1539


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2f612a0fabfb87e79b60f440c05a2cecde424f0
commit b2f612a0fabfb87e79b60f440c05a2cecde424f0
Author: Brad King 
AuthorDate: Thu Nov 30 08:58:01 2017 -0500
Commit: Brad King 
CommitDate: Thu Nov 30 09:50:39 2017 -0500

Simplify CM_FALLTHROUGH implementation

Use the macro now provided by KWSys instead of using `try_compile`
checks.  It will no longer consider the `__attribute__((fallthrough))`
variant, but compilers that don't have one of the modern attributes
shouldn't warn about not using one anyway.

diff --git a/Source/Checks/cm_cxx_attribute_fallthrough.cxx 
b/Source/Checks/cm_cxx_attribute_fallthrough.cxx
deleted file mode 100644
index 50605b7..000
--- a/Source/Checks/cm_cxx_attribute_fallthrough.cxx
+++ /dev/null
@@ -1,11 +0,0 @@
-int main(int argc, char* [])
-{
-  int i = 3;
-  switch (argc) {
-case 1:
-  i = 0;
-  __attribute__((fallthrough));
-default:
-  return i;
-  }
-}
diff --git a/Source/Checks/cm_cxx_fallthrough.cxx 
b/Source/Checks/cm_cxx_fallthrough.cxx
deleted file mode 100644
index 2825bed..000
--- a/Source/Checks/cm_cxx_fallthrough.cxx
+++ /dev/null
@@ -1,11 +0,0 @@
-int main(int argc, char* [])
-{
-  int i = 3;
-  switch (argc) {
-case 1:
-  i = 0;
-  [[fallthrough]];
-default:
-  return i;
-  }
-}
diff --git a/Source/Checks/cm_cxx_features.cmake 
b/Source/Checks/cm_cxx_features.cmake
index a30a5e6..2704c40 100644
--- a/Source/Checks/cm_cxx_features.cmake
+++ b/Source/Checks/cm_cxx_features.cmake
@@ -41,13 +41,6 @@ function(cm_check_cxx_feature name)
   endif()
 endfunction()
 
-cm_check_cxx_feature(fallthrough)
-if(NOT CMake_HAVE_CXX_FALLTHROUGH)
-  cm_check_cxx_feature(gnu_fallthrough)
-  if(NOT CMake_HAVE_CXX_GNU_FALLTHROUGH)
-cm_check_cxx_feature(attribute_fallthrough)
-  endif()
-endif()
 cm_check_cxx_feature(make_unique)
 if(CMake_HAVE_CXX_MAKE_UNIQUE)
   set(CMake_HAVE_CXX_UNIQUE_PTR 1)
diff --git a/Source/Checks/cm_cxx_gnu_fallthrough.cxx 
b/Source/Checks/cm_cxx_gnu_fallthrough.cxx
deleted file mode 100644
index ebc15f4..000
--- a/Source/Checks/cm_cxx_gnu_fallthrough.cxx
+++ /dev/null
@@ -1,11 +0,0 @@
-int main(int argc, char* [])
-{
-  int i = 3;
-  switch (argc) {
-case 1:
-  i = 0;
-  [[gnu::fallthrough]];
-default:
-  return i;
-  }
-}
diff --git a/Source/cmConfigure.cmake.h.in b/Source/cmConfigure.cmake.h.in
index 9a78aca..c80439b 100644
--- a/Source/cmConfigure.cmake.h.in
+++ b/Source/cmConfigure.cmake.h.in
@@ -19,22 +19,11 @@
 #cmakedefine HAVE_UNSETENV
 #cmakedefine CMAKE_USE_ELF_PARSER
 #cmakedefine CMAKE_USE_MACH_PARSER
-#cmakedefine CMake_HAVE_CXX_FALLTHROUGH
-#cmakedefine CMake_HAVE_CXX_GNU_FALLTHROUGH
-#cmakedefine CMake_HAVE_CXX_ATTRIBUTE_FALLTHROUGH
 #cmakedefine CMake_HAVE_CXX_MAKE_UNIQUE
 #define CMAKE_BIN_DIR "/@CMAKE_BIN_DIR@"
 #define CMAKE_DATA_DIR "/@CMAKE_DATA_DIR@"
 
-#if