[Cmake-commits] CMake branch, master, updated. v3.9.2-809-g6b76615

[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  6b76615c4e55dc93fbe6880151a4a24ae700987b (commit)
  from  90b931e115fa6da965135a3a2160e2efbeac2379 (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=6b76615c4e55dc93fbe6880151a4a24ae700987b
commit 6b76615c4e55dc93fbe6880151a4a24ae700987b
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Sep 15 00:01:03 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Sep 15 00:01:03 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 49fe6f2..8ba34f2 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 9)
-set(CMake_VERSION_PATCH 20170914)
+set(CMake_VERSION_PATCH 20170915)
 #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

Re: [CMake] Adding compile and build type tests to CMake/CTest

[Edward Diener]

On 9/14/2017 4:45 PM, Bill Hoffman wrote:

On 9/12/2017 1:11 PM, Robert Ramey wrote:


Could we get some response on Edward's suggestion here? It's a serious 
obstacle to implementing support of CMake in Boost libraries.
I don't think it would be a problem to implement something like this in 
CMake.  It might make more sense to move this conversation to the 
cmake-developers list where we can discuss the particulars of the 
interface and implementation. Then we can figure out how to get it 
implemented.


Edward, did you want to start the discussion on the cmake-developers list?


It looks like my subscription to the CMake developers list went through.



Thanks.

-Bill








--

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] Adding compile and build type tests to CMake/CTest

[Edward Diener]

On 9/14/2017 4:45 PM, Bill Hoffman wrote:

On 9/12/2017 1:11 PM, Robert Ramey wrote:


Could we get some response on Edward's suggestion here? It's a serious 
obstacle to implementing support of CMake in Boost libraries.
I don't think it would be a problem to implement something like this in 
CMake.  It might make more sense to move this conversation to the 
cmake-developers list where we can discuss the particulars of the 
interface and implementation. Then we can figure out how to get it 
implemented.


Edward, did you want to start the discussion on the cmake-developers list?


I am not a CMake developer and I have been unable to subscribe to the 
CMake developer's list. But if you want to move my request to the CMake 
developers list please go ahead.




Thanks.

-Bill


--

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] cmake-server protocol versioning

[Justin Goshi via cmake-developers]

Thank you very much for the information.

As I learn more about cmake-server and figure out what we are using on our end 
I would be happy to contribute tests where it makes sense.

It would be great to move cmake-server towards removing the experimental tag.

Justin

-Original Message-
From: Tobias Hunger [mailto:tobias.hun...@gmail.com] 
Sent: Thursday, September 14, 2017 10:47 AM
To: Justin Goshi 
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] cmake-server protocol versioning

Hi Justin,

On Thu, Sep 14, 2017 at 6:52 PM, Justin Goshi via cmake-developers 
 wrote:
> I work at Microsoft on the version of CMake shipping with Visual 
> Studio, and we use the cmake-server to talk to CMake.

Cool!

> At some point between cmake version 3.9.0 and 3.9.1 the cmake-server 
> protocol changed. Looking through the source code, I see that 
> cmServerProtocol1::ProtocolVersion now returns 1,1 when it used to 
> return 1,0. Has there been discussion about backwards compatibility? 
> In particular we were thinking something along these lines would be nice.

Please ask the server for version 1, not 1.0 (leave the minor part 
unspecified). That way server-mode will always return the latest minor version 
that is available.

> Every change to the information returned from CMake increments the 
> protocol number

It does. As new functionality gets added, the version number increases, as you 
noted.

> CMake –server supports all protocol numbers by letting you specify 
> which one you are requesting. Extra data that is ignored is okay with 
> older protocols, but it can’t change the expected data.

That is what minor increments do: They add extra stuff that older clients 
should simply ignore. This means new fields might get added to the JSON output, 
or new commands may become available. Nothing that should throw a client off 
balance:-) Minor version bumps are mostly there to make clients aware that new 
features are available.

Major version bumps break compatibility with clients that expect earlier major 
versions. We will keep the old version of the protocol supported when that 
happens -- as far as that is possible.

> CMake –server has tests to verify it supports older protocol numbers.

Tests are available for a lot of the things that server-mode does.
They did not detect a regression compared to protocol 1.0 when we changed to 
1.1.

I would welcome if you could find the time to help improve our test coverage 
with use-cases critical to you.

> What are your thoughts?

I basically agree with what you said. But please be aware that server-mode is 
still experimental, so we do currently have a bit of slack as we figure out 
things.

We should discuss removing the experimental tag though.

Best Regards,
Tobias
-- 

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] cmake-server protocol versioning

[Tobias Hunger]

Hi Justin,

On Thu, Sep 14, 2017 at 6:52 PM, Justin Goshi via cmake-developers
 wrote:
> I work at Microsoft on the version of CMake shipping with Visual Studio, and
> we use the cmake-server to talk to CMake.

Cool!

> At some point between cmake version 3.9.0 and 3.9.1 the cmake-server
> protocol changed. Looking through the source code, I see that
> cmServerProtocol1::ProtocolVersion now returns 1,1 when it used to return
> 1,0. Has there been discussion about backwards compatibility? In particular
> we were thinking something along these lines would be nice.

Please ask the server for version 1, not 1.0 (leave the minor part
unspecified). That way server-mode will always return the latest minor
version that is available.

> Every change to the information returned from CMake increments the protocol
> number

It does. As new functionality gets added, the version number
increases, as you noted.

> CMake –server supports all protocol numbers by letting you specify which one
> you are requesting. Extra data that is ignored is okay with older protocols,
> but it can’t change the expected data.

That is what minor increments do: They add extra stuff that older
clients should simply ignore. This means new fields might get added to
the JSON output, or new commands may become available. Nothing that
should throw a client off balance:-) Minor version bumps are mostly
there to make clients aware that new features are available.

Major version bumps break compatibility with clients that expect
earlier major versions. We will keep the old version of the protocol
supported when that happens -- as far as that is possible.

> CMake –server has tests to verify it supports older protocol numbers.

Tests are available for a lot of the things that server-mode does.
They did not detect a regression compared to protocol 1.0 when we
changed to 1.1.

I would welcome if you could find the time to help improve our test
coverage with use-cases critical to you.

> What are your thoughts?

I basically agree with what you said. But please be aware that
server-mode is still experimental, so we do currently have a bit of
slack as we figure out things.

We should discuss removing the experimental tag though.

Best Regards,
Tobias
-- 

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] Adding compile and build type tests to CMake/CTest

[Bill Hoffman]

On 9/12/2017 1:11 PM, Robert Ramey wrote:


Could we get some response on Edward's suggestion here? It's a serious 
obstacle to implementing support of CMake in Boost libraries.
I don't think it would be a problem to implement something like this in 
CMake.  It might make more sense to move this conversation to the 
cmake-developers list where we can discuss the particulars of the 
interface and implementation. Then we can figure out how to get it 
implemented.


Edward, did you want to start the discussion on the cmake-developers list?

Thanks.

-Bill





--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
--

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, master, updated. v3.9.2-808-g90b931e

[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  90b931e115fa6da965135a3a2160e2efbeac2379 (commit)
   via  a7a6ae5edde8a7c091822998da76846d0befc163 (commit)
  from  0865a24fc1c47d75f1381659ba398e6944c9a724 (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=90b931e115fa6da965135a3a2160e2efbeac2379
commit 90b931e115fa6da965135a3a2160e2efbeac2379
Merge: 0865a24 a7a6ae5e
Author: Brad King 
AuthorDate: Thu Sep 14 18:50:59 2017 +
Commit: Kitware Robot 
CommitDate: Thu Sep 14 14:51:05 2017 -0400

Merge topic 'doc-RunCMake-result'

a7a6ae5e Tests: Update RunCMake/README.rst to clarify meaning of -result.txt

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7a6ae5edde8a7c091822998da76846d0befc163
commit a7a6ae5edde8a7c091822998da76846d0befc163
Author: Brad King 
AuthorDate: Thu Sep 14 14:15:26 2017 -0400
Commit: Brad King 
CommitDate: Thu Sep 14 14:15:26 2017 -0400

Tests: Update RunCMake/README.rst to clarify meaning of -result.txt

The content of `-result.txt` files is a regex, but the documentation
didn't make this clear.

Suggested-by: Deniz Bahadir 

diff --git a/Tests/RunCMake/README.rst b/Tests/RunCMake/README.rst
index 4aae4ae..08b51d9 100644
--- a/Tests/RunCMake/README.rst
+++ b/Tests/RunCMake/README.rst
@@ -47,11 +47,11 @@ but do not actually build anything.  To add a test:
containing expected test results:
 
``-result.txt``
-Process result expected if not "0"
+Regex matching expected process result, if not ``0``
``-stdout.txt``
 Regex matching expected stdout content
``-stderr.txt``
-Regex matching expected stderr content, if not "^$"
+Regex matching expected stderr content, if not ``^$``
``-check.cmake``
 Custom result check.
 

---

Summary of changes:
 Tests/RunCMake/README.rst |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


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

[cmake-developers] cmake-server protocol versioning

[Justin Goshi via cmake-developers]

I work at Microsoft on the version of CMake shipping with Visual Studio, and we 
use the cmake-server to talk to CMake.

At some point between cmake version 3.9.0 and 3.9.1 the cmake-server protocol 
changed. Looking through the source code, I see that 
cmServerProtocol1::ProtocolVersion now returns 1,1 when it used to return 1,0. 
Has there been discussion about backwards compatibility? In particular we were 
thinking something along these lines would be nice.

  *   Every change to the information returned from CMake increments the 
protocol number
  *   CMake -server supports all protocol numbers by letting you specify which 
one you are requesting. Extra data that is ignored is okay with older 
protocols, but it can't change the expected data.
  *   CMake -server has tests to verify it supports older protocol numbers.

What are your thoughts?

Thank you.
Justin

-- 

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] Understanding constraint graph cycles

[Robert Maynard]

Yes,

You most likely want to look at BUILD_RPATH or INSTALL_RPATH depending
on if these libraries are located in your build directory or install
directory.

On Mon, Sep 4, 2017 at 4:39 PM, James Turner  wrote:
>
> On 4 Sep 2017, at 18:37, Robert Maynard  wrote:
>
> Yes you are correct the issue is related to rpath. When CMake constructs the
> rpath for the library linking it will have two paths (
> /home/jenkins/workspace/FlightGear/dist/lib64,
> /home/jenkins/workspace/SimGear/dist/lib64) each that contain a copy of
> libosgText.so.130. CMake is warning that which version of libosgText is
> undefined.
>
>
> Can I control whether CMake includes the rpath flags for a static library
> like SimGear? Normally the default behaviour is correct but for this
> particular config it would be easier to disable the rpath for OSG inside
> SimGear, than adjust the build setup to use a common dist dir, I think.
>
> Kind regards,
> James
>
-- 

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, master, updated. v3.9.2-806-g0865a24

[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  0865a24fc1c47d75f1381659ba398e6944c9a724 (commit)
   via  01b9d039e71aaaf69cf23330fc4129e888e40ea0 (commit)
   via  9c7bf6974f7e50e795e0ca960834909e14cdd7a0 (commit)
   via  5202075c66c242e00fc0da118b63428009d1947e (commit)
   via  208ac575312717223bfc61f57072ff61db790b86 (commit)
   via  badc892ff8ea48b499694bc1dc94b5bac272531b (commit)
   via  31f73eb12dd0888efc61c0333539d1354c7268ce (commit)
   via  f95dceccb5ccb1ba3ce54173dc4a0b7fdc4144a3 (commit)
   via  a3deae71990e0fd6b495bb3e925755cdbcaf89eb (commit)
   via  9f66fe9a01451cb5a6e883b05dbc05d6c6c6f4f7 (commit)
   via  64e973e991636f296cb2bf4f3c0e4ec26463a7b1 (commit)
   via  c5b5bb270f54dab4ff529688a26ea8aa271fa0e1 (commit)
   via  c2cc91a4a549346d5d8a76a5c4ac497e28b4bd3b (commit)
  from  fda9a94fe6061908e1d66c111f9030baa62cccf7 (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=0865a24fc1c47d75f1381659ba398e6944c9a724
commit 0865a24fc1c47d75f1381659ba398e6944c9a724
Merge: 01b9d03 badc892
Author: Brad King 
AuthorDate: Thu Sep 14 07:41:02 2017 -0400
Commit: Brad King 
CommitDate: Thu Sep 14 07:41:02 2017 -0400

Merge branch 'release-3.9'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=01b9d039e71aaaf69cf23330fc4129e888e40ea0
commit 01b9d039e71aaaf69cf23330fc4129e888e40ea0
Merge: 9c7bf69 31f73eb
Author: Brad King 
AuthorDate: Thu Sep 14 11:39:08 2017 +
Commit: Kitware Robot 
CommitDate: Thu Sep 14 07:39:24 2017 -0400

Merge topic 'get_filename_component-fix-program-split'

31f73eb1 get_filename_component: Revise PROGRAM/PROGRAM_ARGS split semantics

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c7bf6974f7e50e795e0ca960834909e14cdd7a0
commit 9c7bf6974f7e50e795e0ca960834909e14cdd7a0
Merge: 5202075 c2cc91a
Author: Brad King 
AuthorDate: Thu Sep 14 11:38:08 2017 +
Commit: Kitware Robot 
CommitDate: Thu Sep 14 07:38:29 2017 -0400

Merge topic 'remove-nmcl'

c2cc91a4 Platforms: Remove Windows-NMcl

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5202075c66c242e00fc0da118b63428009d1947e
commit 5202075c66c242e00fc0da118b63428009d1947e
Merge: 208ac57 a3deae7
Author: Brad King 
AuthorDate: Thu Sep 14 11:37:30 2017 +
Commit: Kitware Robot 
CommitDate: Thu Sep 14 07:37:58 2017 -0400

Merge topic 'bootstrap-twice-in-source'

a3deae71 bootstrap: Fix running multiple times in-source

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=208ac575312717223bfc61f57072ff61db790b86
commit 208ac575312717223bfc61f57072ff61db790b86
Merge: fda9a94 64e973e
Author: Brad King 
AuthorDate: Thu Sep 14 11:37:05 2017 +
Commit: Kitware Robot 
CommitDate: Thu Sep 14 07:37:16 2017 -0400

Merge topic 'vs-fix-config-map'

64e973e9 Merge branch 'backport-vs-fix-config-map' into vs-fix-config-map
c5b5bb27 VS: Do not consider MAP_IMPORTED_CONFIG_ on non-imported 
targets

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=31f73eb12dd0888efc61c0333539d1354c7268ce
commit 31f73eb12dd0888efc61c0333539d1354c7268ce
Author: Brad King 
AuthorDate: Mon Sep 11 11:05:20 2017 -0400
Commit: Brad King 
CommitDate: Wed Sep 13 10:47:04 2017 -0400

get_filename_component: Revise PROGRAM/PROGRAM_ARGS split semantics

The KWSys `SystemTools::SplitProgramFromArgs` implementation goes into
an infinite loop when the value is just " " (a space).  Since the
"program path with unquoted spaces plus command-line arguments"
operation it is trying to provide is poorly defined (string parsing
should not depend on filesystem content), just stop using it.

Instead consider the main two use cases the old approach tried to handle:

* The value is the name or absolute path of a program with no quoting
  or escaping, but also no command-line arguments.  In this case we
  can use the value as given with no parsing, and assume no arguments.

* The value is a 

[Cmake-commits] CMake branch, release, updated. v3.9.2-7-gbadc892

[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  badc892ff8ea48b499694bc1dc94b5bac272531b (commit)
   via  b494308dab7ca3fe94ce558c71bcaf1a8e6d (commit)
   via  d0f1581719644cc9b40a3ad4425bd37369f11c7e (commit)
   via  f95dceccb5ccb1ba3ce54173dc4a0b7fdc4144a3 (commit)
   via  a3deae71990e0fd6b495bb3e925755cdbcaf89eb (commit)
   via  9f66fe9a01451cb5a6e883b05dbc05d6c6c6f4f7 (commit)
   via  c5b5bb270f54dab4ff529688a26ea8aa271fa0e1 (commit)
  from  ffa164736ec78f27583ca4515ff3dfc7a82fc702 (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:
 Source/cmGlobalVisualStudio71Generator.cxx |   14 +-
 Source/cmGlobalVisualStudio8Generator.cxx  |   14 +-
 Source/cmQtAutoGeneratorInitializer.cxx|   85 +++---
 Tests/QtAutogen/mocDepends/CMakeLists.txt  |  168 
 .../{invalid.hpp.in => object_invalid.hpp.in}  |0
 .../{object.hpp.in => object_valid.hpp.in} |0
 Tests/QtAutogen/mocDepends/simpleLib.hpp.in|5 +-
 Tests/QtAutogen/mocDepends/test2.cpp   |   10 --
 Tests/QtAutogen/mocDepends/testATDFile.cpp |9 ++
 Tests/QtAutogen/mocDepends/testATDTarget.cpp   |9 ++
 .../mocDepends/{test1.cpp => testGenFile.cpp}  |3 +-
 Tests/QtAutogen/mocDepends/testGenLib.cpp  |   12 ++
 .../mocDepends/{test2.hpp => testGenLib.hpp}   |4 +-
 Tests/QtAutogen/mocDepends/testGenTarget.cpp   |9 ++
 bootstrap  |6 +
 15 files changed, 268 insertions(+), 80 deletions(-)
 rename Tests/QtAutogen/mocDepends/{invalid.hpp.in => object_invalid.hpp.in} 
(100%)
 rename Tests/QtAutogen/mocDepends/{object.hpp.in => object_valid.hpp.in} (100%)
 delete mode 100644 Tests/QtAutogen/mocDepends/test2.cpp
 create mode 100644 Tests/QtAutogen/mocDepends/testATDFile.cpp
 create mode 100644 Tests/QtAutogen/mocDepends/testATDTarget.cpp
 rename Tests/QtAutogen/mocDepends/{test1.cpp => testGenFile.cpp} (65%)
 create mode 100644 Tests/QtAutogen/mocDepends/testGenLib.cpp
 rename Tests/QtAutogen/mocDepends/{test2.hpp => testGenLib.hpp} (83%)
 create mode 100644 Tests/QtAutogen/mocDepends/testGenTarget.cpp


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.9.2-793-gfda9a94

[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  fda9a94fe6061908e1d66c111f9030baa62cccf7 (commit)
   via  06c8a37e5816f2431b469b37961588f494fefcd4 (commit)
   via  b494308dab7ca3fe94ce558c71bcaf1a8e6d (commit)
   via  d0f1581719644cc9b40a3ad4425bd37369f11c7e (commit)
  from  d6b49ee6767e8b21eee08d218ca5f599ad8f978b (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=fda9a94fe6061908e1d66c111f9030baa62cccf7
commit fda9a94fe6061908e1d66c111f9030baa62cccf7
Merge: d6b49ee 06c8a37
Author: Brad King 
AuthorDate: Thu Sep 14 11:19:33 2017 +
Commit: Kitware Robot 
CommitDate: Thu Sep 14 07:19:40 2017 -0400

Merge topic 'autogen-target-depends-fix-3-9-2'

06c8a37e Merge branch 'backport-autogen-target-depends' into 
autogen-target-depends-fix-3-9-2
b494308d Autogen: Tests: Backport tests for _autogen target dependencies
d0f15817 Autogen: Backport autogen target dependency as file dependency fix

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=06c8a37e5816f2431b469b37961588f494fefcd4
commit 06c8a37e5816f2431b469b37961588f494fefcd4
Merge: 420874b b494308
Author: Brad King 
AuthorDate: Wed Sep 13 15:09:36 2017 -0400
Commit: Brad King 
CommitDate: Wed Sep 13 15:09:36 2017 -0400

Merge branch 'backport-autogen-target-depends' into 
autogen-target-depends-fix-3-9-2

Use the "ours" merge strategy because we already have equivalent
changes on our side.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b494308dab7ca3fe94ce558c71bcaf1a8e6d
commit b494308dab7ca3fe94ce558c71bcaf1a8e6d
Author: Sebastian Holtermann 
AuthorDate: Wed Sep 13 18:31:50 2017 +0200
Commit: Brad King 
CommitDate: Wed Sep 13 15:07:46 2017 -0400

Autogen: Tests: Backport tests for _autogen target dependencies

diff --git a/Tests/QtAutogen/mocDepends/CMakeLists.txt 
b/Tests/QtAutogen/mocDepends/CMakeLists.txt
index a67dcfe..6241ef9 100644
--- a/Tests/QtAutogen/mocDepends/CMakeLists.txt
+++ b/Tests/QtAutogen/mocDepends/CMakeLists.txt
@@ -1,5 +1,5 @@
-cmake_minimum_required(VERSION 3.7)
-project(mocDepends)
+cmake_minimum_required(VERSION 3.9)
+project(mocDepends CXX)
 
 if (QT_TEST_VERSION STREQUAL 4)
   find_package(Qt4 REQUIRED)
@@ -14,34 +14,138 @@ else()
 endif()
 
 include_directories(${CMAKE_CURRENT_BINARY_DIR})
+set(CSD ${CMAKE_CURRENT_SOURCE_DIR})
+set(CBD ${CMAKE_CURRENT_BINARY_DIR})
 
-# -- Test 1 using generated header
-# This tests the dependency of AUTOMOC of mocDepends1 to the generated 
object.hpp
-add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/object.hpp
-   COMMAND ${CMAKE_COMMAND} -E copy 
${CMAKE_CURRENT_SOURCE_DIR}/invalid.hpp.in 
${CMAKE_CURRENT_BINARY_DIR}/object.hpp
-   COMMAND ${CMAKE_COMMAND} -E sleep 3
-   COMMAND ${CMAKE_COMMAND} -E copy 
${CMAKE_CURRENT_SOURCE_DIR}/object.hpp.in ${CMAKE_CURRENT_BINARY_DIR}/object.hpp
-   )
-
-add_executable(mocDepends1 test1.cpp
-  ${CMAKE_CURRENT_BINARY_DIR}/object.hpp
-)
-target_link_libraries(mocDepends1 ${QT_CORE_TARGET})
-set_target_properties(mocDepends1 PROPERTIES AUTOMOC TRUE)
-set_property(TARGET mocDepends1 PROPERTY 
__UNDOCUMENTED_AUTOGEN_GENERATED_FILES 1)
-
-# -- Test 2 using generated library
-# This tests the dependency of AUTOMOC of mocDepends2 to the
-# generated simpleLib.hpp which belongs to a linked library of mocDepends2
-add_custom_command(OUTPUT simpleLib.hpp simpleLib.cpp
-   COMMAND ${CMAKE_COMMAND} -E copy 
${CMAKE_CURRENT_SOURCE_DIR}/invalid.hpp.in 
${CMAKE_CURRENT_BINARY_DIR}/simpleLib.hpp
-   COMMAND ${CMAKE_COMMAND} -E sleep 3
-   COMMAND ${CMAKE_COMMAND} -E copy 
${CMAKE_CURRENT_SOURCE_DIR}/simpleLib.hpp.in 
${CMAKE_CURRENT_BINARY_DIR}/simpleLib.hpp
-   COMMAND ${CMAKE_COMMAND} -E copy 
${CMAKE_CURRENT_SOURCE_DIR}/simpleLib.cpp.in 
${CMAKE_CURRENT_BINARY_DIR}/simpleLib.cpp
-   )
-add_library(SimpleLib STATIC simpleLib.hpp simpleLib.cpp)
-
-add_executable(mocDepends2 test2.cpp )
-target_link_libraries(mocDepends2 SimpleLib ${QT_CORE_TARGET})
-set_target_properties(mocDepends2 PROPERTIES AUTOMOC TRUE)
-set_property(TARGET mocDepends2 PROPERTY 
__UNDOCUMENTED_AUTOGEN_GENERATED_FILES 1)
+# -- Test dependency on header generated by a custom command
+#
+# The ORIGIN_autogen target must depend on the same *GENERATED*