Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 11/09/2016 09:06 PM, Ruslan Baratov wrote:



So why the project in the middle of the migration process is not a valid
case? It is maintained but the exact migration step is paused, but I
have an intention to improve the code in future. Anyway even if the
project is no longer maintained, then what we have? We have
`cmake_minimum_required` with the version that fits **features** the
code has and `cmake_policy` to control the **behavior** of different
cmake versions.


Temporary use during migration to a new CMake version is one of the use 
cases explicitly mentioned in the documentation.
But when you say you might migrate some time in the future that makes it 
sound like you aren't actually in the process of migration but are 
rather looking for some loophole.





Or as I said cmake's testsuite.

If you insist on actual code e.g. this is part of the tests that I
wrote for CMP0054:
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/CMP0054/CMP0054-NEW.cmake;h=23a912476024ba09fcf741e04f999b64a6e91450;hb=refs/heads/master


The internal CMake stuff is out of the scope of discussion. If policies
are the internals why do we need them in the documentation?


Well you could have excluded the case when I brought it up initially 
preferably before asking for code.

I don't have any unmaintained public projects in mind that I could link to.
But then again as I said before the code itself is entirely irrelevant; 
what counts is the context.


Nils
--

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.7.0-rc3-460-g7c09bcf

[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  7c09bcfee81ab651e04505d29eb1c5e35fb673ce (commit)
  from  88f38a2bb42599561e685dfba956866d857fe518 (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=7c09bcfee81ab651e04505d29eb1c5e35fb673ce
commit 7c09bcfee81ab651e04505d29eb1c5e35fb673ce
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu Nov 10 00:01:04 2016 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu Nov 10 00:01:04 2016 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b1549a1..59afc47 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 20161109)
+set(CMake_VERSION_PATCH 20161110)
 #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] Is there a default value for CMAKE_MODULE_PATH?

[Jayesh Badwaik]

All of these version work, but because of the various kinds of automated 
setups I use, the command line options seems the best compromise. 

However, I realized that I have a include file in my source code which is 
ignored from the source control since it is user/system dependent, and I have 
put my config there now. 

Thanks a lot for your help. 

-- 
Cheers
Jayesh Badwaik
https://www.jayeshbadwaik.in

signature.asc
Description: This is a digitally signed message part.
-- 

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 Cmake version in online documentation

[Ruslan Baratov via CMake]

On 09-Nov-16 23:00, Nils Gladitz wrote:
> On 09.11.2016 15:52, Ruslan Baratov wrote:
>> Can you show the real code? The code that in your opinion doesn't
>> violate the "right way of policy usage"?
>
> It is not a question about code. It is a question about context and
> use case.
You just said that all the code I've showed is not correct and conflicts
with policies nature. So I have to ask you about the real code, because
looks like in your "world" there is no valid case of `cmake_policy`
usage and the only correct way to set policies is to use
`cmake_minimum_required` command. Hence it's not surprising that you
can't distinguish `cmake_minimum_required` and behavior controlled by
`cmake_policy`.

>
> Valid context as the documentation states would e.g. be a project that
> is no longer maintained where you have no intention of ever migrating
> to a newer CMake version.
So why the project in the middle of the migration process is not a valid
case? It is maintained but the exact migration step is paused, but I
have an intention to improve the code in future. Anyway even if the
project is no longer maintained, then what we have? We have
`cmake_minimum_required` with the version that fits **features** the
code has and `cmake_policy` to control the **behavior** of different
cmake versions.

> Or as I said cmake's testsuite.
>
> If you insist on actual code e.g. this is part of the tests that I
> wrote for CMP0054:
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/CMP0054/CMP0054-NEW.cmake;h=23a912476024ba09fcf741e04f999b64a6e91450;hb=refs/heads/master
>
The internal CMake stuff is out of the scope of discussion. If policies
are the internals why do we need them in the documentation?

Ruslo


-- 

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] Add property to get all linked libraries including transitive ones

[Brad King]

On 11/09/2016 01:28 PM, maikel van den Hurk wrote:
>> Stephen Kelly wrote:
>> I believe it's because of a chicken-egg concern - the link libraries are the
>> basis for transitivity for other properties. I remember discussing that in
>> the mailing list back in the design phase.
> 
> When trying to remove the limitation I couldn't find any issue actually.

I think what may have happened was that originally we attempted to make
the value of each usage requirement property itself (get_property) have
the transitive closure already filled out.  Later we changed to making
the property itself non-transitive but have the genex evaluation take care
of transitivity instead.  This means there is no chicken-n-egg problem
for LINK_LIBRARIES anymore.

> I can make a PR on gitlab which will make this possible.

Thanks.  Note that changing $ behavior
will require a policy.

-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-developers] Add property to get all linked libraries including transitive ones

[maikel van den Hurk]

When trying to remove the limitation I couldn't find any issue actually. Do I 
overlook something here? If not I can make a PR on gitlab which will make this 
possible.


Maikel



Van: cmake-developers  namens Stephen Kelly 

Verzonden: maandag 7 november 2016 01:23
Aan: cmake-developers@cmake.org
Onderwerp: Re: [cmake-developers] Add property to get all linked libraries 
including transitive ones

Brad King wrote:

> On 11/04/2016 09:52 AM, maikel van den Hurk wrote:
>> What about doing what was targeted with this bug:
>> https://cmake.org/Bug/view.php?id=12435?
>
> That issue is now tracked here:
>
>  https://gitlab.kitware.com/cmake/cmake/issues/12435
[https://gitlab.kitware.com/uploads/project/avatar/541/cmakelogo-centered.png]

Possibility to get all link libraries for a target? (#12435) · Issues · CMake / 
CMake
gitlab.kitware.com
This issue was created automatically from an original [Mantis 
Issue](https://cmake.org/Bug/view.php?id=12435). Further discussion may take 
place here.



>
> I've just added some notes to the discussion.
>
> Steve, do you recall why $
> is not transitive as genexes for other usage requirements are?

I believe it's because of a chicken-egg concern - the link libraries are the
basis for transitivity for other properties. I remember discussing that in
the mailing list back in the design phase.

Thanks,

Steve.


--

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

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] Is there a default value for CMAKE_MODULE_PATH?

[Wagner, David]

On 09/11/2016 16:05, Jayesh Badwaik wrote:

Hi,

TL;DR
Is there a default value for CMAKE_MODULE_PATH which allows me to use a module
file from inside my PROJECT_SOURCE_DIR.

Context:
Over past few days, Boost has updated from version 1.61 to version 1.62. The
latest version of CMake that I have (3.6.3) does not yet have the appropriate
FindBoost.cmake and hence, issues warnings as shown in the postscript.



Have you tried setting Boost_ADDITIONAL_VERSIONS ? c.f FindBoost's 
documentation:


   Boost_ADDITIONAL_VERSIONS
  - List of Boost versions not known to this module
(Boost install locations may contain the version)


I don't know what changed in Boost 1.62 but doing so may be enough for you.

Alternatively, you can set CMAKE_MODULE_PATH by hand in your command line.

BR
David

--
David Wagner

complex != complicated
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France

Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--

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-rc3-1007-g404e3eb

[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  404e3ebc4f512d912a07d12de897931463c9df3c (commit)
   via  96d23ca9a55e112c167e39535d5e132e046954a0 (commit)
   via  7a941d91d3a7b864008d0e15b8a2ace1c6b88b85 (commit)
  from  db87aa33be07ed5234f948316a1483f716e3ecb7 (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=404e3ebc4f512d912a07d12de897931463c9df3c
commit 404e3ebc4f512d912a07d12de897931463c9df3c
Merge: db87aa3 96d23ca
Author: Brad King 
AuthorDate: Wed Nov 9 11:48:16 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 11:48:16 2016 -0500

Merge topic 'import-librhash' into next

96d23ca9 librhash: Avoid signed left-shift overflow
7a941d91 librhash: Implement bswap_32 as a function even in strict C90 mode


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96d23ca9a55e112c167e39535d5e132e046954a0
commit 96d23ca9a55e112c167e39535d5e132e046954a0
Author: Brad King 
AuthorDate: Wed Nov 9 11:43:34 2016 -0500
Commit: Brad King 
CommitDate: Wed Nov 9 11:43:34 2016 -0500

librhash: Avoid signed left-shift overflow

Fix `rhash_md5_final` to use unsigned integers for left shifting to
avoid the possibility of undefined overflow behavior.

diff --git a/Utilities/cmlibrhash/librhash/md5.c 
b/Utilities/cmlibrhash/librhash/md5.c
index 0feb090..b20de45 100644
--- a/Utilities/cmlibrhash/librhash/md5.c
+++ b/Utilities/cmlibrhash/librhash/md5.c
@@ -213,8 +213,8 @@ void rhash_md5_final(md5_ctx *ctx, unsigned char* result)
/* pad message and run for last block */
 
/* append the byte 0x80 to the message */
-   ctx->message[index]   &= ~(0x << shift);
-   ctx->message[index++] ^= 0x80 << shift;
+   ctx->message[index]   &= ~(0xu << shift);
+   ctx->message[index++] ^= 0x80u << shift;
 
/* if no room left in the message to store 64-bit message length */
if (index > 14) {

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a941d91d3a7b864008d0e15b8a2ace1c6b88b85
commit 7a941d91d3a7b864008d0e15b8a2ace1c6b88b85
Author: Brad King 
AuthorDate: Wed Nov 9 11:38:54 2016 -0500
Commit: Brad King 
CommitDate: Wed Nov 9 11:41:36 2016 -0500

librhash: Implement bswap_32 as a function even in strict C90 mode

We cannot fall back to the macro implementation because some call sites
may call it with an argument like `*ptr++` that has side effects.

diff --git a/Utilities/cmlibrhash/librhash/byte_order.h 
b/Utilities/cmlibrhash/librhash/byte_order.h
index fe49e26..d34a020 100644
--- a/Utilities/cmlibrhash/librhash/byte_order.h
+++ b/Utilities/cmlibrhash/librhash/byte_order.h
@@ -71,6 +71,10 @@ void rhash_swap_copy_str_to_u64(void* to, int index, const 
void* from, size_t le
 void rhash_swap_copy_u64_to_str(void* to, const void* from, size_t length);
 void rhash_u32_mem_swap(unsigned *p, int length_in_u32);
 
+#ifndef __has_builtin
+# define __has_builtin(x) 0
+#endif
+
 /* define bswap_32 */
 #if defined(__GNUC__) && defined(CPU_IA32) && !defined(__i386__)
 /* for intel x86 CPU */
@@ -81,23 +85,18 @@ static inline uint32_t bswap_32(uint32_t x) {
 #elif defined(__GNUC__)  && (__GNUC__ >= 4) && (__GNUC__ > 4 || __GNUC_MINOR__ 
>= 3)
 /* for GCC >= 4.3 */
 # define bswap_32(x) __builtin_bswap32(x)
+#elif defined(__clang__) && __has_builtin(__builtin_bswap32)
+# define bswap_32(x) __builtin_bswap32(x)
 #elif (_MSC_VER > 1300) && (defined(CPU_IA32) || defined(CPU_X64)) /* MS VC */
 # define bswap_32(x) _byteswap_ulong((unsigned long)x)
-#elif !defined(__STRICT_ANSI__)
+#else
 /* general bswap_32 definition */
-static inline uint32_t bswap_32(uint32_t x) {
+static uint32_t bswap_32(uint32_t x) {
x = ((x << 8) & 0xFF00FF00) | ((x >> 8) & 0x00FF00FF);
return (x >> 16) | (x << 16);
 }
-#else
-#define bswap_32(x) x) & 0xff00) >> 24) | (((x) & 0x00ff) >>  8) | 
\
-   (((x) & 0xff00) <<  8) | (((x) & 0x00ff) << 24))
 #endif /* bswap_32 */
 
-#ifndef __has_builtin
-# define __has_builtin(x) 0
-#endif
-
 #if defined(__GNUC__) && (__GNUC__ >= 4) && (__GNUC__ > 4 || __GNUC_MINOR__ >= 
3)
 # define bswap_64(x) __builtin_bswap64(x)
 #elif defined(__clang__) && __has_builtin(__builtin_bswap64)

---

Summary of changes:
 Utilities/cmlibrhash/librhash/byte_order.h |   17 -
 Utilities/cmlibrhash/librhash/md5.c|4 ++--
 2 files changed, 10 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-1004-gdb87aa3

[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  db87aa33be07ed5234f948316a1483f716e3ecb7 (commit)
   via  e4232b82e6d285edf9038e2f352df61ab362b6fd (commit)
  from  7d34c8eb67d557a6eefe1ca7980ff00906bd0f9f (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=db87aa33be07ed5234f948316a1483f716e3ecb7
commit db87aa33be07ed5234f948316a1483f716e3ecb7
Merge: 7d34c8e e4232b8
Author: Brad King 
AuthorDate: Wed Nov 9 11:26:22 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 11:26:22 2016 -0500

Merge topic 'autorcc-only-no-rebuild' into next

e4232b82 QtAutogen: Do not re-generate AUTORCC outputs on every build


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4232b82e6d285edf9038e2f352df61ab362b6fd
commit e4232b82e6d285edf9038e2f352df61ab362b6fd
Author: Brad King 
AuthorDate: Wed Nov 9 11:05:45 2016 -0500
Commit: Brad King 
CommitDate: Wed Nov 9 11:22:07 2016 -0500

QtAutogen: Do not re-generate AUTORCC outputs on every build

Refactoring in commit v3.6.0-rc1~134^2~10 (Autogen: Split out moc file
generation code to dedicated method, 2016-04-18) removed the
unconditional creation of the `_automoc.cpp` file.  Now it is
generated only when `AUTOMOC` is enabled.  However, if this file is not
created then our internal `GenerateAll` setting is enabled on every
build, causing `AUTORCC` to re-generate its file(s) every time.  Fix the
`GenerateAll` setting to be used only for when autogen settings change.
The old logic was left from when we had only automoc.

Closes: #16413

diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index b66257c..84d00ea 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -455,8 +455,8 @@ static std::string ReadAll(const std::string& filename)
 
 bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
 {
-  if (!cmsys::SystemTools::FileExists(this->OutMocCppFilenameAbs.c_str()) ||
-  (this->OldCompileSettingsStr != this->CurrentCompileSettingsStr)) {
+  // If settings changed everything needs to be re-generated.
+  if (this->OldCompileSettingsStr != this->CurrentCompileSettingsStr) {
 this->GenerateAll = true;
   }
 

---

Summary of changes:
 Source/cmQtAutoGenerators.cxx |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

Re: [cmake-developers] cmake 3.7.0-rc3 regression

[Robert Goulet]

Ok thanks, we'll just build CMake for all platform from now on.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Tuesday, November 8, 2016 2:13 PM
To: Robert Goulet 
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] cmake 3.7.0-rc3 regression

On 11/08/2016 01:59 PM, Robert Goulet wrote:
> Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b
> Add option to control 'bin' directory of CMake's own installation 
> (#16076)

I suspect it is caused by this hunk:

> -  // Install tree has "/bin/cmake" and "".
> -  std::string dir = cmSystemTools::GetFilenamePath(exe_dir);
> -  cmSystemToolsCMakeRoot = dir + CMAKE_DATA_DIR;
> -  if (!cmSystemTools::FileExists(
> +  // Install tree has
> +  // - "/cmake"
> +  // - ""
> +  if (cmHasSuffix(exe_dir, CMAKE_BIN_DIR)) {
> +std::string const prefix =
> +  exe_dir.substr(0, exe_dir.size() - strlen(CMAKE_BIN_DIR));
> +cmSystemToolsCMakeRoot = prefix + CMAKE_DATA_DIR;  }  if 
> + (cmSystemToolsCMakeRoot.empty() ||
> +  !cmSystemTools::FileExists(

Prior to that we would blindly strip one directory off the location no matter 
its name.  Now we need to look for and strip the exactly-configured name of the 
bin directory because it may be more than one layer deep.

CMake locates its own resources relative to its executable in order to make it 
relocatable.  This means we don't expect the layout of the install tree to be 
changed after installation.  You're doing that, so your use case is not 
supported.

However, what the above commit did was give you a first-class way of supporting 
your use case by building with `CMAKE_BIN_DIR` set to the platform-specific 
name.  You can use that to achieve the same result.

Alternatively, if you *really* want to support your original use case you can 
work on a change to the above logic to count the number of path components in 
CMAKE_BIN_DIR and strip that many blindly instead of looking for the exact 
suffix.  I won't be holding up 3.7 for that though.

-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] Adding Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 15:52, Ruslan Baratov wrote:
Can you show the real code? The code that in your opinion doesn't 
violate the "right way of policy usage"?


It is not a question about code. It is a question about context and use 
case.


Valid context as the documentation states would e.g. be a project that 
is no longer maintained where you have no intention of ever migrating to 
a newer CMake version.

Or as I said cmake's testsuite.

If you insist on actual code e.g. this is part of the tests that I wrote 
for CMP0054:

https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/CMP0054/CMP0054-NEW.cmake;h=23a912476024ba09fcf741e04f999b64a6e91450;hb=refs/heads/master

Again the code itself is irrelevant here; what matters is the context.

Nils


--

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] PDB_NAME with DEBUG_POSTFIX

[Carl Poirier]

Hi folks,

A few months later, would anyone have an explanation for this?

Thank you,

Carl

On Fri, Feb 19, 2016 at 9:07 AM, Carl Poirier 
wrote:

> Hi folks,
>
> I have a question here regarding the use of the DEBUG_POSTFIX. When I set
> it as well as the property OUTPUT_NAME, the former is correctly applied to
> the latter. Now when I try to do so with a library, the DEBUG_POSTFIX does
> not get applied to the PDB filename. Here are the relevant lines of my
> CMakeLists.txt:
>
> # Set the resulting filenames
> set_target_properties(${PrjName1} PROPERTIES COMPILE_PDB_NAME mylib)
> set_target_properties(${PrjName1} PROPERTIES OUTPUT_NAME mylib)
>
> # Add "D" postfix for the debug build
> set_target_properties(${PrjName1} PROPERTIES DEBUG_POSTFIX "D")
>
> So is there a reason why it works (or doesn't) that way? The best
> workaround I have now is set the names on a per-configuration basis.
>
> Regards,
>
> Carl
>
-- 

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] Is there a default value for CMAKE_MODULE_PATH?

[Jayesh Badwaik]

Hi,

TL;DR
Is there a default value for CMAKE_MODULE_PATH which allows me to use a module 
file from inside my PROJECT_SOURCE_DIR.

Context:
Over past few days, Boost has updated from version 1.61 to version 1.62. The 
latest version of CMake that I have (3.6.3) does not yet have the appropriate 
FindBoost.cmake and hence, issues warnings as shown in the postscript. 

As I see this is temporary, and there is a correct FindBoost.cmake in the git 
repository which works fine. So, I want to use this new module file till the 
time when the new version of CMake comes out and I won't have to use this 
special file anymore. 

All the solutions that I have found on internet require me to put a line 
setting the CMAKE_MODULE_PATH in my project source code. I don't want to do it 
since the change is supposed to be temporary anyway. So, I was wondering if 
there is a location inside the PROJECT_SOURCE_DIR which is scanned by default 
by cmake?

If there is no such location, I can live with the warnings for a little while, 
but I was just curious.


-- 
Cheers
Jayesh Badwaik
https://www.jayeshbadwaik.in

=
CMake Warnings
=
CMake Warning at /usr/share/cmake-3.6/Modules/FindBoost.cmake:743 (message):
  Imported targets not available for Boost version 106200
Call Stack (most recent call first):
  /usr/share/cmake-3.6/Modules/FindBoost.cmake:842 
(_Boost_COMPONENT_DEPENDENCIES)
  /usr/share/cmake-3.6/Modules/FindBoost.cmake:1395 
(_Boost_MISSING_DEPENDENCIES)
  CMakeLists.txt:48 (find_package)

signature.asc
Description: This is a digitally signed message part.
-- 

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 Cmake version in online documentation

[Ruslan Baratov via CMake]

Can you show the real code? The code that in your opinion doesn't
violate the "right way of policy usage"?

On 09-Nov-16 22:14, Nils Gladitz wrote:
> On 09.11.2016 14:57, Ruslan Baratov wrote:
>>
>> Again policies are not meant to be feature toggles.
>> You can do a lot of things and there may be valid use cases but in
>> general policies are not meant to be used this way.
>> This is made explicit in CMake's documentation on policies.
>> They exist to preserve backwards compatibility not to pick and choose
>> behaviours.
>>
>> So can you show an example of "valid" use of `cmake_policy` command?
>>
>
> To quote the documentation:
> "A policy is a deprecation mechanism and not a reliable feature
> toggle. A policy should almost never be set to |OLD|, except to
> silence warnings in an otherwise frozen or stable codebase, or
> temporarily as part of a larger migration path."
>
> Beyond that valid use would be e.g. cmake's own testsuite which needs
> to be able to toggle individual policies to verify their behaviour.
>
> Nils
>

-- 

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-rc3-1002-g7d34c8e

[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  7d34c8eb67d557a6eefe1ca7980ff00906bd0f9f (commit)
   via  88f38a2bb42599561e685dfba956866d857fe518 (commit)
   via  64b5b06dc61db74ef2f994ec4d0f4277113fb49e (commit)
   via  e2565be52c7d80a4993c749282210e5b599cbc32 (commit)
   via  72190b923bd19bc9f9bddc6958ebb0cec28a5b98 (commit)
   via  453df662bafe52ec87e0972323cf87ec737f3437 (commit)
   via  25085f41b20f7f5a5fb25e8ab683f77476f917a2 (commit)
  from  327c10aef394d0d4ed08c681f742196360709cb7 (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=7d34c8eb67d557a6eefe1ca7980ff00906bd0f9f
commit 7d34c8eb67d557a6eefe1ca7980ff00906bd0f9f
Merge: 327c10a 88f38a2
Author: Brad King 
AuthorDate: Wed Nov 9 09:50:12 2016 -0500
Commit: Brad King 
CommitDate: Wed Nov 9 09:50:12 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-rc3-450-g453df66

[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  453df662bafe52ec87e0972323cf87ec737f3437 (commit)
   via  09cda9d5e7bb31f05177bdaf11d24aeaf85a8dd3 (commit)
   via  1d1f1eeb6a52d464d476eb0a46eb75c452e3dfbc (commit)
   via  479932fa32115b666be1deea42862673a0c4b608 (commit)
   via  925e4270fdc5c731c123cb8037607840008f4713 (commit)
  from  25085f41b20f7f5a5fb25e8ab683f77476f917a2 (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=453df662bafe52ec87e0972323cf87ec737f3437
commit 453df662bafe52ec87e0972323cf87ec737f3437
Merge: 25085f4 09cda9d
Author: Brad King 
AuthorDate: Wed Nov 9 09:49:49 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 09:49:49 2016 -0500

Merge topic 'imported-interface-libname'

09cda9d5 Allow imported INTERFACE libraries to specify a link library name
1d1f1eeb cmTarget: Refactor GetMappedConfig to choose location property up 
front
479932fa cmTarget: Add comment clarifying interface library special case
925e4270 cmTarget: Clarify comments in GetMappedConfig


---

Summary of changes:
 Help/manual/cmake-properties.7.rst |2 +
 Help/prop_tgt/IMPORTED_LIBNAME.rst |   23 +++
 Help/prop_tgt/IMPORTED_LIBNAME_CONFIG.rst  |7 ++
 Help/release/dev/imported-interface-libname.rst|7 ++
 Source/cmComputeLinkInformation.cxx|6 ++
 Source/cmGeneratorTarget.cxx   |   13 
 Source/cmGeneratorTarget.h |4 ++
 Source/cmTarget.cxx|   71 +++-
 Source/cmTarget.h  |3 +
 Source/cmTargetPropertyComputer.cxx|4 +-
 Tests/InterfaceLibrary/CMakeLists.txt  |   19 +-
 Tests/InterfaceLibrary/definetestexe.cpp   |3 +-
 .../InterfaceLibrary/item.cpp  |2 +-
 Tests/InterfaceLibrary/item_fake.cpp   |5 ++
 .../IMPORTED_LIBNAME-bad-value-result.txt} |0
 .../IMPORTED_LIBNAME-bad-value-stderr.txt  |   44 
 .../IMPORTED_LIBNAME-bad-value.cmake   |6 ++
 .../IMPORTED_LIBNAME-non-iface-result.txt} |0
 .../IMPORTED_LIBNAME-non-iface-stderr.txt  |   45 +
 .../IMPORTED_LIBNAME-non-iface.cmake   |   17 +
 .../IMPORTED_LIBNAME-non-imported-result.txt}  |0
 .../IMPORTED_LIBNAME-non-imported-stderr.txt   |   21 ++
 .../IMPORTED_LIBNAME-non-imported.cmake|5 ++
 .../RunCMake/interface_library/RunCMakeTest.cmake  |3 +
 24 files changed, 288 insertions(+), 22 deletions(-)
 create mode 100644 Help/prop_tgt/IMPORTED_LIBNAME.rst
 create mode 100644 Help/prop_tgt/IMPORTED_LIBNAME_CONFIG.rst
 create mode 100644 Help/release/dev/imported-interface-libname.rst
 copy Modules/DummyCXXFile.cxx => Tests/InterfaceLibrary/item.cpp (59%)
 create mode 100644 Tests/InterfaceLibrary/item_fake.cpp
 copy Tests/RunCMake/{Android/BadSYSROOT-result.txt => 
interface_library/IMPORTED_LIBNAME-bad-value-result.txt} (100%)
 create mode 100644 
Tests/RunCMake/interface_library/IMPORTED_LIBNAME-bad-value-stderr.txt
 create mode 100644 
Tests/RunCMake/interface_library/IMPORTED_LIBNAME-bad-value.cmake
 copy Tests/RunCMake/{Android/BadSYSROOT-result.txt => 
interface_library/IMPORTED_LIBNAME-non-iface-result.txt} (100%)
 create mode 100644 
Tests/RunCMake/interface_library/IMPORTED_LIBNAME-non-iface-stderr.txt
 create mode 100644 
Tests/RunCMake/interface_library/IMPORTED_LIBNAME-non-iface.cmake
 copy Tests/RunCMake/{Android/BadSYSROOT-result.txt => 
interface_library/IMPORTED_LIBNAME-non-imported-result.txt} (100%)
 create mode 100644 
Tests/RunCMake/interface_library/IMPORTED_LIBNAME-non-imported-stderr.txt
 create mode 100644 
Tests/RunCMake/interface_library/IMPORTED_LIBNAME-non-imported.cmake


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-rc3-456-g64b5b06

[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  64b5b06dc61db74ef2f994ec4d0f4277113fb49e (commit)
   via  36f9f0f8a3e7640c12034fff8871b779cba9f0ce (commit)
  from  e2565be52c7d80a4993c749282210e5b599cbc32 (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=64b5b06dc61db74ef2f994ec4d0f4277113fb49e
commit 64b5b06dc61db74ef2f994ec4d0f4277113fb49e
Merge: e2565be 36f9f0f
Author: Brad King 
AuthorDate: Wed Nov 9 09:49:58 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 09:49:58 2016 -0500

Merge topic 'drop-kwstyle'

36f9f0f8 Drop KWStyle checks in favor of clang-format and Git hooks


---

Summary of changes:
 Tests/CMakeLists.txt |   14 --
 Utilities/CMakeLists.txt |2 +-
 Utilities/KWStyle/CMake.kws.xml.in   |   11 
 Utilities/KWStyle/CMakeFiles.txt.in  |   15 --
 Utilities/KWStyle/CMakeLists.txt |   69 --
 Utilities/KWStyle/CMakeMoreChecks.kws.xml.in |   30 ---
 6 files changed, 1 insertion(+), 140 deletions(-)
 delete mode 100644 Utilities/KWStyle/CMake.kws.xml.in
 delete mode 100644 Utilities/KWStyle/CMakeFiles.txt.in
 delete mode 100644 Utilities/KWStyle/CMakeLists.txt
 delete mode 100644 Utilities/KWStyle/CMakeMoreChecks.kws.xml.in
 delete mode 100644 Utilities/KWStyle/CMakeOverwrite.txt


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-rc3-459-g88f38a2

[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  88f38a2bb42599561e685dfba956866d857fe518 (commit)
   via  95a97a40e48a0db2b206c4560d6962be3666812c (commit)
   via  773b36e5d4af3ac040625e0ea16bcfd30fcdeb6d (commit)
  from  64b5b06dc61db74ef2f994ec4d0f4277113fb49e (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=88f38a2bb42599561e685dfba956866d857fe518
commit 88f38a2bb42599561e685dfba956866d857fe518
Merge: 64b5b06 95a97a4
Author: Brad King 
AuthorDate: Wed Nov 9 09:50:01 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 09:50:01 2016 -0500

Merge topic 'update-kwsys'

95a97a40 Merge branch 'upstream-KWSys' into update-kwsys
773b36e5 KWSys 2016-11-09 (18c65411)


---

Summary of changes:
 Source/kwsys/Base64.c  |  218 +-
 Source/kwsys/Base64.h.in   |   82 +-
 Source/kwsys/CMakeLists.txt|   13 +-
 Source/kwsys/CONTRIBUTING.rst  |   13 +
 Source/kwsys/CTestConfig.cmake |   14 +-
 Source/kwsys/CommandLineArguments.cxx  |  786 +++--
 Source/kwsys/CommandLineArguments.hxx.in   |  133 +-
 Source/kwsys/Configure.h.in|  167 +-
 Source/kwsys/Configure.hxx.in  |   29 +-
 Source/kwsys/ConsoleBuf.hxx.in |  629 ++--
 Source/kwsys/Copyright.txt |   17 +-
 Source/kwsys/Directory.cxx |  140 +-
 Source/kwsys/Directory.hxx.in  |   23 +-
 Source/kwsys/DynamicLoader.cxx |  229 +-
 Source/kwsys/DynamicLoader.hxx.in  |   43 +-
 Source/kwsys/Encoding.h.in |   58 +-
 Source/kwsys/Encoding.hxx.in   |   72 +-
 Source/kwsys/EncodingC.c   |   53 +-
 Source/kwsys/EncodingCXX.cxx   |  110 +-
 Source/kwsys/FStream.cxx   |   67 +-
 Source/kwsys/FStream.hxx.in|  428 ++-
 Source/kwsys/Glob.cxx  |  416 +--
 Source/kwsys/Glob.hxx.in   |   64 +-
 Source/kwsys/IOStream.cxx  |  245 +-
 Source/kwsys/IOStream.hxx.in   |  136 +-
 Source/kwsys/MD5.c |  523 ++--
 Source/kwsys/MD5.h.in  |   64 +-
 Source/kwsys/Process.h.in  |  260 +-
 Source/kwsys/ProcessUNIX.c | 2078 ++
 Source/kwsys/ProcessWin32.c| 1837 +---
 Source/kwsys/RegularExpression.cxx | 1666 ++-
 Source/kwsys/RegularExpression.hxx.in  |  148 +-
 Source/kwsys/SharedForward.h.in|  604 ++--
 Source/kwsys/String.c  |   97 +-
 Source/kwsys/String.h.in   |   36 +-
 Source/kwsys/String.hxx.in |   62 +-
 Source/kwsys/System.c  |  221 +-
 Source/kwsys/System.h.in   |   32 +-
 Source/kwsys/SystemInformation.cxx | 4303 ++--
 Source/kwsys/SystemInformation.hxx.in  |   61 +-
 Source/kwsys/SystemTools.cxx   | 3905 ++---
 Source/kwsys/SystemTools.hxx.in|  294 +-
 Source/kwsys/Terminal.c|  315 +-
 Source/kwsys/Terminal.h.in |  191 +-
 Source/kwsys/hash_fun.hxx.in   |   89 +-
 Source/kwsys/hash_map.hxx.in   |  246 +-
 Source/kwsys/hash_set.hxx.in   |  217 +-
 Source/kwsys/hashtable.hxx.in  |  486 ++--
 Source/kwsys/kwsysHeaderDump.pl|   13 +-
 Source/kwsys/kwsysPlatformTests.cmake  |   14 +-
 Source/kwsys/kwsysPlatformTestsC.c |   52 +-
 Source/kwsys/kwsysPlatformTestsCXX.cxx |  147 +-
 Source/kwsys/kwsysPrivate.h|   19 +-
 Source/kwsys/testCommandLineArguments.cxx  |  201 +-
 Source/kwsys/testCommandLineArguments1.cxx |   83 +-
 Source/kwsys/testConsoleBuf.cxx|  412 +--
 Source/kwsys/testConsoleBuf.hxx|   20 +-
 Source/kwsys/testConsoleBufChild.cxx   |   18 +-
 Source/kwsys/testDynamicLoader.cxx |   89 +-
 Source/kwsys/testDynload.c |   15 +-
 Source/kwsys/testEncode.c  |   31 +-
 Source/kwsys/testEncoding.cxx  |  130 +-
 Source/kwsys/testFStream.cxx   |  114 +-
 Source/kwsys/testFail.c|   31 +-
 Source/kwsys/testHashSTL.cxx   |   37 +-
 Source/kwsys/testIOS.cxx   |  153 +-
 Source/kwsys/testProcess.c |  454 ++-
 

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc3-454-ge2565be

[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  e2565be52c7d80a4993c749282210e5b599cbc32 (commit)
   via  f18b18b72b8f7f8dc21e350f4dd1c6931cdb389f (commit)
  from  72190b923bd19bc9f9bddc6958ebb0cec28a5b98 (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=e2565be52c7d80a4993c749282210e5b599cbc32
commit e2565be52c7d80a4993c749282210e5b599cbc32
Merge: 72190b9 f18b18b
Author: Brad King 
AuthorDate: Wed Nov 9 09:49:56 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 09:49:56 2016 -0500

Merge topic 'FindSDL_preventGrowingCacheVar'

f18b18b7 FindSDL: Prevent unbounded growth of SDL_LIBRARY_TEMP variable


---

Summary of changes:
 Modules/FindSDL.cmake |7 +--
 1 file changed, 5 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, master, updated. v3.7.0-rc3-452-g72190b9

[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  72190b923bd19bc9f9bddc6958ebb0cec28a5b98 (commit)
   via  61898de64180ce8123219f5e6450cb8375840045 (commit)
  from  453df662bafe52ec87e0972323cf87ec737f3437 (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=72190b923bd19bc9f9bddc6958ebb0cec28a5b98
commit 72190b923bd19bc9f9bddc6958ebb0cec28a5b98
Merge: 453df66 61898de
Author: Brad King 
AuthorDate: Wed Nov 9 09:49:53 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 09:49:53 2016 -0500

Merge topic 'pkgconfig_imported_target'

61898de6 PkgConfig: Fix FindPkgConfig imported target feature


---

Summary of changes:
 Modules/FindPkgConfig.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] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe

[Saad Khattak]

Hmm, maybe...? I'm not sure. Customize may be the wrong word. What I'm
asking in the question is similar to someone asking "how do I customize the
output path for the binaries in CMake?". My hope was it was going to be a
simple set variable for the utilities.

On Wed, Nov 9, 2016, 7:56 AM Jakob van Bethlehem 
wrote:

> Hej,
>
> On Mon, Nov 7, 2016 at 4:48 PM, Saad Khattak  wrote:
>
> I am working on a plugin for Maya and it uses a customized version of Qt.
> Maya's SDK comes with everything to build Qt (headers, libraries and
> customized Qt tools such as moc.exe).
>
> I have the following issues:
>
> (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point
> CMake to pick Maya's version of moc.exe (and other Qt utils). The result is
> that I get linking errors since the moc did not run - which I expected.
>
> (2) Maya uses a modified version of Qt 5.6.1. There is currently no way to
> get that version from Autodesk. So I downloaded the official Qt 5.6.1
> distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed.
> However, it is using the official Qt moc utilities and NOT Maya's
> customized moc. The headers and libraries being used were still from Maya's
> custom Qt.
>
> The reason (2) worked is because I put "find_package(Qt5Widgets REQUIRED)"
> after installing the official version of Qt 5.6.1. However, I did NOT use
> the official Qt headers or libraries - instead, I used Maya's custom
> version of Qt 5.6.1.
>
> Using solution (2) I successfully compile and link my Qt enabled Maya
> plugin and load it in Maya. Things go smoothly until I either (a) unload
> the plugin or (b) delete any widget. I looked at the simplest code that is
> causing a heap corruption debug assertion:
>
> m_button = new QPushButton("MyButton"); // where m_button is a QPointer
> 
> delete m_button; // causes heap corruption debug assertion to fire
>
> A few other people have gone through similar issues but since they didn't
> use CMake, they simply ran Maya's moc utilities in a build step. I would
> like a solution where I can get CMAKE_AUTOMOC to run the custom Qt version.
>
> Thanks.
>
>
> I see quite a lot usage of the word 'customized'. to me it sounds like
> you may be asking on the wrong user list?
>
> Sincerely,
> Jakob
>
>
>
-- 

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-rc3-995-g327c10a

[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  327c10aef394d0d4ed08c681f742196360709cb7 (commit)
   via  09cda9d5e7bb31f05177bdaf11d24aeaf85a8dd3 (commit)
  from  257e6ad4e1ce5d6735ae7cb7bdce1defc7abf2d7 (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=327c10aef394d0d4ed08c681f742196360709cb7
commit 327c10aef394d0d4ed08c681f742196360709cb7
Merge: 257e6ad 09cda9d
Author: Brad King 
AuthorDate: Wed Nov 9 09:45:59 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 09:45:59 2016 -0500

Merge topic 'imported-interface-libname' into next

09cda9d5 Allow imported INTERFACE libraries to specify a link library name


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09cda9d5e7bb31f05177bdaf11d24aeaf85a8dd3
commit 09cda9d5e7bb31f05177bdaf11d24aeaf85a8dd3
Author: Brad King 
AuthorDate: Thu Nov 3 16:44:32 2016 -0400
Commit: Brad King 
CommitDate: Wed Nov 9 09:45:14 2016 -0500

Allow imported INTERFACE libraries to specify a link library name

Add an `IMPORTED_LIBNAME[_]` target property to specify a library
name to be placed on the link line in place of an interface library
since it has no library file of its own.  Restrict use of the property
to imported `INTERFACE` libraries.

This will be particularly useful for find modules that need to provide
imported libraries from system SDKs where the full path to the library
file is not known.  Now such find modules will be able to provide an
imported interface library and set `IMPORTED_LIBNAME` to refer to the
SDK library by name.

Issue: #15267

diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index fa21a1f..82d5588 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -167,6 +167,8 @@ Properties on Targets
/prop_tgt/IMPORTED_CONFIGURATIONS
/prop_tgt/IMPORTED_IMPLIB_CONFIG
/prop_tgt/IMPORTED_IMPLIB
+   /prop_tgt/IMPORTED_LIBNAME_CONFIG
+   /prop_tgt/IMPORTED_LIBNAME
/prop_tgt/IMPORTED_LINK_DEPENDENT_LIBRARIES_CONFIG
/prop_tgt/IMPORTED_LINK_DEPENDENT_LIBRARIES
/prop_tgt/IMPORTED_LINK_INTERFACE_LANGUAGES_CONFIG
diff --git a/Help/prop_tgt/IMPORTED_LIBNAME.rst 
b/Help/prop_tgt/IMPORTED_LIBNAME.rst
new file mode 100644
index 000..1943dba
--- /dev/null
+++ b/Help/prop_tgt/IMPORTED_LIBNAME.rst
@@ -0,0 +1,23 @@
+IMPORTED_LIBNAME
+
+
+Specify the link library name for an :ref:`imported `
+:ref:`Interface Library `.
+
+An interface library builds no library file itself but does specify
+usage requirements for its consumers.  The ``IMPORTED_LIBNAME``
+property may be set to specify a single library name to be placed
+on the link line in place of the interface library target name as
+a requirement for using the interface.
+
+This property is intended for use in naming libraries provided by
+a platform SDK for which the full path to a library file may not
+be known.  The value may be a plain library name such as ``foo``
+but may *not* be a path (e.g. ``/usr/lib/libfoo.so``) or a flag
+(e.g. ``-Wl,...``).  The name is never treated as a library target
+name even if it happens to name one.
+
+The ``IMPORTED_LIBNAME`` property is allowed only on
+:ref:`imported ` :ref:`Interface Libraries`
+and is rejected on targets of other types (for which
+the :prop_tgt:`IMPORTED_LOCATION` target property may be used).
diff --git a/Help/prop_tgt/IMPORTED_LIBNAME_CONFIG.rst 
b/Help/prop_tgt/IMPORTED_LIBNAME_CONFIG.rst
new file mode 100644
index 000..a28b838
--- /dev/null
+++ b/Help/prop_tgt/IMPORTED_LIBNAME_CONFIG.rst
@@ -0,0 +1,7 @@
+IMPORTED_LIBNAME_
+-
+
+-specific version of :prop_tgt:`IMPORTED_LIBNAME` property.
+
+Configuration names correspond to those provided by the project from
+which the target is imported.
diff --git a/Help/release/dev/imported-interface-libname.rst 
b/Help/release/dev/imported-interface-libname.rst
new file mode 100644
index 000..fdbae78
--- /dev/null
+++ b/Help/release/dev/imported-interface-libname.rst
@@ -0,0 +1,7 @@
+imported-interface-libname
+--
+
+* :ref:`Imported ` :ref:`Interface Libraries` learned new
+  :prop_tgt:`IMPORTED_LIBNAME` and :prop_tgt:`IMPORTED_LIBNAME_`
+  target properties to specify a link library name since interface libraries
+  do not build their own library files.
diff --git a/Source/cmComputeLinkInformation.cxx 
b/Source/cmComputeLinkInformation.cxx
index 28aa533..80e7e7d 100644
--- 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-990-g32d0a8a

[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  32d0a8a1ac3254ea029bee283358d782f0609414 (commit)
   via  d2c565f6f707e94cf0e77261033e72ffbd3b2109 (commit)
   via  966a7e290c81308ef6185d18de6bcc11e43643d3 (commit)
  from  807ac5d9a3ab9ea13f8b918347cff1c18aebe66c (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=32d0a8a1ac3254ea029bee283358d782f0609414
commit 32d0a8a1ac3254ea029bee283358d782f0609414
Merge: 807ac5d d2c565f
Author: Brad King 
AuthorDate: Wed Nov 9 09:22:47 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 09:22:47 2016 -0500

Merge topic 'update-kwsys' into next

d2c565f6 Merge branch 'upstream-KWSys' into update-kwsys
966a7e29 KWSys 2016-11-09 (18c65411)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d2c565f6f707e94cf0e77261033e72ffbd3b2109
commit d2c565f6f707e94cf0e77261033e72ffbd3b2109
Merge: 35c6358 966a7e2
Author: Brad King 
AuthorDate: Wed Nov 9 09:22:28 2016 -0500
Commit: Brad King 
CommitDate: Wed Nov 9 09:22:28 2016 -0500

Merge branch 'upstream-KWSys' into update-kwsys

* upstream-KWSys:
  KWSys 2016-11-09 (18c65411)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=966a7e290c81308ef6185d18de6bcc11e43643d3
commit 966a7e290c81308ef6185d18de6bcc11e43643d3
Author: KWSys Upstream 
AuthorDate: Wed Nov 9 09:12:29 2016 -0500
Commit: Brad King 
CommitDate: Wed Nov 9 09:22:13 2016 -0500

KWSys 2016-11-09 (18c65411)

Code extracted from:

http://public.kitware.com/KWSys.git

at commit 18c654114de3aa65429542f95308720bc68f9231 (master).

Upstream Shortlog
-

Brad King (1):
  18c65411 FStream: Include Configure.hxx before other headers

diff --git a/FStream.hxx.in b/FStream.hxx.in
index 4db81a4..736214f 100644
--- a/FStream.hxx.in
+++ b/FStream.hxx.in
@@ -3,9 +3,11 @@
 #ifndef @KWSYS_NAMESPACE@_FStream_hxx
 #define @KWSYS_NAMESPACE@_FStream_hxx
 
-#include 
 #include <@KWSYS_NAMESPACE@/Configure.hxx>
+
 #include <@KWSYS_NAMESPACE@/Encoding.hxx>
+
+#include 
 #if defined(_WIN32)
 #if !defined(_MSC_VER) && @KWSYS_NAMESPACE@_CXX_HAS_EXT_STDIO_FILEBUF_H
 #include 

---

Summary of changes:
 Source/kwsys/FStream.hxx.in |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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-987-g807ac5d

[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  807ac5d9a3ab9ea13f8b918347cff1c18aebe66c (commit)
   via  8037cc12f59a607a6bbc7a65ede915bc31bf61b5 (commit)
  from  5b83bdc894c0501feed78ea1b86ff299ed8274a6 (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=807ac5d9a3ab9ea13f8b918347cff1c18aebe66c
commit 807ac5d9a3ab9ea13f8b918347cff1c18aebe66c
Merge: 5b83bdc 8037cc1
Author: Brad King 
AuthorDate: Wed Nov 9 09:22:02 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 09:22:02 2016 -0500

Merge topic 'import-librhash' into next

8037cc12 fixup! librhash: Remove source fragments not needed for CMake


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8037cc12f59a607a6bbc7a65ede915bc31bf61b5
commit 8037cc12f59a607a6bbc7a65ede915bc31bf61b5
Author: Brad King 
AuthorDate: Wed Nov 9 08:33:38 2016 -0500
Commit: Brad King 
CommitDate: Wed Nov 9 08:33:38 2016 -0500

fixup! librhash: Remove source fragments not needed for CMake

diff --git a/Utilities/cmlibrhash/librhash/rhash.h 
b/Utilities/cmlibrhash/librhash/rhash.h
index 2437072..6d18c18 100644
--- a/Utilities/cmlibrhash/librhash/rhash.h
+++ b/Utilities/cmlibrhash/librhash/rhash.h
@@ -153,6 +153,7 @@ RHASH_API const char* rhash_get_magnet_name(unsigned 
hash_id); /* get name part
 /* note, that rhash_info_by_id() is not exported to a shared library or DLL */
 const rhash_info* rhash_info_by_id(unsigned hash_id); /* get hash sum info by 
hash id */
 
+#if 0
 /**
  * Flags for printing a hash sum
  */
@@ -185,6 +186,7 @@ enum rhash_print_sum_flags
/** print file size in rhash_print_magnet */
RHPR_FILESIZE  = 0x40,
 };
+#endif
 
 /* output hash into the given buffer */
 RHASH_API size_t rhash_print_bytes(char* output,

---

Summary of changes:
 Utilities/cmlibrhash/librhash/rhash.h |2 ++
 1 file changed, 2 insertions(+)


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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 14:57, Ruslan Baratov wrote:


Again policies are not meant to be feature toggles.
You can do a lot of things and there may be valid use cases but in 
general policies are not meant to be used this way.

This is made explicit in CMake's documentation on policies.
They exist to preserve backwards compatibility not to pick and choose 
behaviours.


So can you show an example of "valid" use of `cmake_policy` command?



To quote the documentation:
"A policy is a deprecation mechanism and not a reliable feature toggle. 
A policy should almost never be set to |OLD|, except to silence warnings 
in an otherwise frozen or stable codebase, or temporarily as part of a 
larger migration path."


Beyond that valid use would be e.g. cmake's own testsuite which needs to 
be able to toggle individual policies to verify their behaviour.


Nils

-- 

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 Cmake version in online documentation

[Ruslan Baratov via CMake]

On 09-Nov-16 19:51, Nils Gladitz wrote:
> On 09.11.2016 12:04, Ruslan Baratov wrote:
>> On 09-Nov-16 16:22, Nils Gladitz wrote:
>>> On 09.11.2016 04:29, Ruslan Baratov wrote:
 On 08-Nov-16 23:33, Nils Gladitz wrote:
> On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
>
>> Except it's exactly opposite :) `cmake_minimum_required` is about
>> new
>> features/commands, and policies is about behavior.
>
> I don't agree and you can not separate the two.
> cmake_minimum_required() initializes the policies based on the
> given version.
 So what? From the user's perspective the "initialization of
 policies" is like a syntactic sugar so you don't have to write
 endless `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal
 with them further.
>>>
>>> You can't simultaneously argue that cmake_minimum_required() isn't
>>> about policies (behaviours) and at the same time syntactic sugar for
>>> those very same policies.
>> You're playing with words instead of using arguments.
>
> There was no word play involved.
> You say cmake_minimum_required() is not about behaviour yet it
> initializes all policies which are purely about behaviour.
>From documentation
(https://cmake.org/cmake/help/latest/command/cmake_minimum_required.html):

The |cmake_minimum_required(VERSION)| command implicitly invokes the
|cmake_policy(VERSION)|


command


So this macro do implicitly invokes the cmake_policy comand:

macro(printvar a)
  cmake_policy(VERSION 3.0)
  message("Variable a: ${a}")
endmacro()

Can we said that 'printvar' affect behaviour? Sure! But what is the
point of this statement in the scope of this discussion?

So similar to your statement:

Strictly speaking cmake_minimum_required(VERSION) is not about command
availability but rather about behavior (cmake policies).


I can say now:

Strictly speaking 'printvar' is not about printing variable but
rather about behavior (cmake policies).

It's hard to argue with this...

>
>>
>>>
>>> Policy warnings aren't meant to indicate errors in your code but
>>> changes in behaviour that will happen if you were to increase your
>>> minimum required version.
>> Policy CMP0038 doesn't agree with you:
>> https://cmake.org/cmake/help/latest/policy/CMP0038.html
>  
> No policies are still primarily about behaviour changes. That is true
> for CMP0038 as well.
>
> The old behaviour is to ignore this issue in user code. The new
> behaviour is to produce an error.
I said that "most of them will be about bugs in my code", so not all of
them about bugs. However you said "warnings aren't meant to indicate
errors" - this statement is wrong, and I have proved it with the link.
The statement that "policies is all about behaviour" is 50% of what I'm
trying to say here.

> When maintainers get this warning they are informed that their code
> will break as soon as they increase their minimum required version.
No, it will not break always because they can control it with policies,
in our case setting policy to OLD will do the trick.

>
> The same is true for CMP0054. The policy warning did find many errors
> in user code but the warning is primarily about the change in behaviour.
And why behaviour changed? Because the way how variables interpreted
before CMP0054 was confusing, dangerous and depend on the value of
unrelated variables from the current scope.

>
>> Yes, like this:
>>
>> cmake_minimum_required(VERSION 2.8)
>> project(foo)
>>
>> if(POLICY CMP0038)cmake_policy(SET CMP0038 OLD) endif()
>>
>> Now CMake 3.0 users will not see the warning and CMake 2.8 users
>> **don't have to upgrade**.
>
> Yes but I don't see what point you are trying to make ... they didn't
> have to upgrade without the explicit policy set either.
> And the policy warnings aren't meant for users they are meant for
> maintainers.
Originally you said that "Given your second example you likely shouldn't
be touching the policy at all". I describe the example when it make
sense and provide the reasons. If you're not interested about warnings
and your users doesn't report the problems they see, then yes, probably
it's fine for you to not to touch the policies.

>
> In fact all that setting it to OLD does is suppress the warning.
>> Actually this statement is wrong. Take a look at this example:
>>
>> # CMakeLists.txt
>> cmake_minimum_required(VERSION 3.0)
>> project(fooVERSION 1.2.3)
>> cmake_policy(SET CMP0038 OLD) # Do not remove this!
>> add_library(foofoo.cpp)
>> target_link_libraries(foofoo)
>>
>> if you remove `cmake_policy(SET CMP0038 OLD)` this example will
>> produce **error**. It may happens when you want to use new
>> **feature** `project(VERSION)` from 3.0, hence you set
>> `cmake_minimum_required(VERSION 3.0)` and simultaneously you have
>> code which produce warning about CMP0038. By setting
>> 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-985-g5b83bdc

[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  5b83bdc894c0501feed78ea1b86ff299ed8274a6 (commit)
   via  c4b0f64b1317656a916162e90621da6d255ab8f1 (commit)
  from  9b7016eea420f6eec2e016d2f694c58eea3e4bbd (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=5b83bdc894c0501feed78ea1b86ff299ed8274a6
commit 5b83bdc894c0501feed78ea1b86ff299ed8274a6
Merge: 9b7016e c4b0f64
Author: Brad King 
AuthorDate: Wed Nov 9 08:26:12 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Nov 9 08:26:12 2016 -0500

Merge topic 'ExternalProject-GIT_CONFIG' into next

c4b0f64b Revert "ExternalProject: Allow passing config flags to git clone"


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4b0f64b1317656a916162e90621da6d255ab8f1
commit c4b0f64b1317656a916162e90621da6d255ab8f1
Author: Brad King 
AuthorDate: Wed Nov 9 08:25:49 2016 -0500
Commit: Brad King 
CommitDate: Wed Nov 9 08:25:49 2016 -0500

Revert "ExternalProject: Allow passing config flags to git clone"

This reverts commit 25cd3e21e86cefa0da6eac0ab54a3adc2d01fb72.
It does not work with older Git versions.

diff --git a/Help/release/dev/ExternalProject-GIT_CONFIG.rst 
b/Help/release/dev/ExternalProject-GIT_CONFIG.rst
deleted file mode 100644
index 0702c55..000
--- a/Help/release/dev/ExternalProject-GIT_CONFIG.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-ExternalProject-GIT_CONFIG
---
-
-* The :module:`ExternalProject` module gained a ``GIT_CONFIG`` option
-  to pass ``git -c`` options when cloning.
diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 84d5d1a..1e0be09 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -73,10 +73,6 @@ Create custom targets to build projects in external trees
 does not output anything which can make the build appear to have stalled.
 This option forces Git to output progress information during the clone step
 so that forward progress is indicated.
-  ``GIT_CONFIG ...``
-Tell Git to clone with ``--config ``.  Use additional configuration
-parameters when cloning the project (``key=value`` as expected by ``git
-config``).
   ``HG_REPOSITORY ``
 URL of mercurial repo
   ``HG_TAG ``
@@ -518,7 +514,7 @@ define_property(DIRECTORY PROPERTY "EP_UPDATE_DISCONNECTED" 
INHERITED
   "ExternalProject module."
   )
 
-function(_ep_write_gitclone_script script_filename source_dir git_EXECUTABLE 
git_repository git_tag git_remote_name git_submodules git_shallow git_progress 
git_config src_name work_dir gitclone_infofile gitclone_stampfile tls_verify)
+function(_ep_write_gitclone_script script_filename source_dir git_EXECUTABLE 
git_repository git_tag git_remote_name git_submodules git_shallow git_progress 
src_name work_dir gitclone_infofile gitclone_stampfile tls_verify)
   if(NOT GIT_VERSION_STRING VERSION_LESS 1.7.10)
 set(git_clone_shallow_options "--depth 1 --no-single-branch")
   else()
@@ -569,11 +565,6 @@ if(git_progress)
   list(APPEND git_clone_options --progress)
 endif()
 
-set(git_config ${git_config})
-foreach(config IN LISTS git_config)
-  list(APPEND git_clone_options --config \${config})
-endforeach()
-
 # try the clone 3 times incase there is an odd git clone issue
 set(error_code 1)
 set(number_of_tries 0)
@@ -1821,7 +1812,6 @@ function(_ep_add_download_command name)
 endif()
 get_property(git_shallow TARGET ${name} PROPERTY _EP_GIT_SHALLOW)
 get_property(git_progress TARGET ${name} PROPERTY _EP_GIT_PROGRESS)
-get_property(git_config TARGET ${name} PROPERTY _EP_GIT_CONFIG)
 
 # For the download step, and the git clone operation, only the repository
 # should be recorded in a configured RepositoryInfo file. If the repo
@@ -1846,7 +1836,7 @@ function(_ep_add_download_command name)
 # The script will delete the source directory and then call git clone.
 #
 _ep_write_gitclone_script(${tmp_dir}/${name}-gitclone.cmake ${source_dir}
-  ${GIT_EXECUTABLE} ${git_repository} ${git_tag} ${git_remote_name} 
"${git_submodules}" "${git_shallow}" "${git_progress}" "${git_config}" 
${src_name} ${work_dir}
+  ${GIT_EXECUTABLE} ${git_repository} ${git_tag} ${git_remote_name} 
"${git_submodules}" "${git_shallow}" "${git_progress}" ${src_name} ${work_dir}
   ${stamp_dir}/${name}-gitinfo.txt 
${stamp_dir}/${name}-gitclone-lastrun.txt "${tls_verify}"
   )
 set(comment "Performing download step (git clone) for '${name}'")
diff --git 

Re: [CMake] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe

[Jakob van Bethlehem]

Hej,

On Mon, Nov 7, 2016 at 4:48 PM, Saad Khattak  wrote:

> I am working on a plugin for Maya and it uses a customized version of Qt.
> Maya's SDK comes with everything to build Qt (headers, libraries and
> customized Qt tools such as moc.exe).
>
> I have the following issues:
>
> (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point
> CMake to pick Maya's version of moc.exe (and other Qt utils). The result is
> that I get linking errors since the moc did not run - which I expected.
>
> (2) Maya uses a modified version of Qt 5.6.1. There is currently no way to
> get that version from Autodesk. So I downloaded the official Qt 5.6.1
> distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed.
> However, it is using the official Qt moc utilities and NOT Maya's
> customized moc. The headers and libraries being used were still from Maya's
> custom Qt.
>
> The reason (2) worked is because I put "find_package(Qt5Widgets REQUIRED)"
> after installing the official version of Qt 5.6.1. However, I did NOT use
> the official Qt headers or libraries - instead, I used Maya's custom
> version of Qt 5.6.1.
>
> Using solution (2) I successfully compile and link my Qt enabled Maya
> plugin and load it in Maya. Things go smoothly until I either (a) unload
> the plugin or (b) delete any widget. I looked at the simplest code that is
> causing a heap corruption debug assertion:
>
> m_button = new QPushButton("MyButton"); // where m_button is a QPointer
> 
> delete m_button; // causes heap corruption debug assertion to fire
>
> A few other people have gone through similar issues but since they didn't
> use CMake, they simply ran Maya's moc utilities in a build step. I would
> like a solution where I can get CMAKE_AUTOMOC to run the custom Qt version.
>
> Thanks.
>
>
I see quite a lot usage of the word 'customized'. to me it sounds like
you may be asking on the wrong user list?

Sincerely,
Jakob
-- 

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] Get libraries from target

[Jakob van Bethlehem]

Hej,

You should be able to query the LINK_LIBRARIES (and maybe some related
properties), see
https://cmake.org/cmake/help/v3.6/prop_tgt/LINK_LIBRARIES.html

Sincerely,
Jakob


On Wed, Nov 9, 2016 at 12:05 AM, Tiago Macarios 
wrote:

> Hi,
>
> Is there a way for me to get CMake libraries out of a target?
>
> For example:
>
> target_link_libraries(A B C)
>
> Can I get B and C from A?
>
> What I am trying to do:
> We are working on adding include-what-you-use into our build system and
> some of the libraries have their on mapping files. So I was wondering if I
> could somehow "attach" the mapping file to the target and then
> "reconstruct" a mapping file for each target.
>
> For example:
>
> Library B and C have their own mapping, so I would:
> set_target_properties(B
> PROPERTIES mapping /path/to/fileB)
> set_target_properties(C
> PROPERTIES mapping /path/to/fileC)
>
> Then a function would reconstruct a mapping for target A:
> set_target_properties(A
> PROPERTIES mapping /path/to/fileA)
>
> create_mapping_function(A):
>  loop over dependencies of A
>  get all mappings
>  recreate a mapping file with all dependencies:
>
> { ref: "/path/to/fileA" },
> { ref: "/path/to/fileB" }
> { ref: "/path/to/fileC" }
>
>
> --
>
> 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

Re: [CMake] Adding Cmake version in online documentation

[Jakob van Bethlehem]

Oops, totally forgot to mention the crux: I happened to be the guy who
apparently was the first to start using continue() - so by the time my
college got to me, we quickly found out the issue. But before the college
hit the problem, I didn't have the vaguest clue that I was typing code that
would require an update of the minimum cmake version.

Honestly, the fact that we don't have some strict policy in our team for
setting version of 3rd parties like CMake, leading to different developers
ending up with different versions, is questionable, yes, of course. It is
the reality however, and my feeling is this is the reality for many more
teams.

Given the copious amount of traffic this issue has generated on this
thread, and in the past(!), it seems no more than reasonable that at least
*something* should happen. I do assume user feedback plays an important
role in deciding where to go with CMake development?

Sincerely,
Jakob

On Wed, Nov 9, 2016 at 1:38 PM, Jakob van Bethlehem <
jsvanbethle...@gmail.com> wrote:

> +1 for me too - sometime ago a college of mine spend quite some time to
> figure why he couldn't bootstrap our application - turns out he was using
> an (old) CMake version which didn't know about the 'continue' command. The
> error-messages coming out of CMake sometimes help, but more often don't
> really give the correct hint, unless you happen to be one of the local
> CMake gurus.
>
> Sincerely,
> Jakob
>
>
> On Tue, Nov 8, 2016 at 10:33 PM, Craig Scott 
> wrote:
>
>> Rather than trying to do everything, perhaps there's value in tackling
>> this in stages. At a high level, simply knowing in which CMake version a
>> particular command, property, variable or module was added is a good start.
>> From there, if a command, etc. gained new options, then a note could be
>> added with the text specific to that option to indicate when it was added.
>> Obviously the more fine grained you go, the more time consuming and onerous
>> it would become, but how about just starting with the coarse level? That
>> already provides a big improvement over the current alternative of wading
>> through past versions of documentation and/or source code.
>>
>> I'd also recommend that such version details be part of the actual CMake
>> docs. While the separate compatibility matrix on the wiki is/was a useful
>> resource, by not having it part of the CMake sources/docs, it is inherently
>> a separate effort to try to keep it up to date with each CMake release.
>> Making it part of CMake itself would seem to encourage documenting version
>> details as part of the same merge requests, etc. that add/change things.
>>
>> I'll go out on a limb here and suggest that if a clear guideline was
>> given for *how* version details should be documented, then the community
>> itself would likely work towards populating that information over time. I
>> don't think there is a (realistic) expectation that Kitware would do all
>> the heavy lifting here.
>>
>>
>>
>> On Wed, Nov 9, 2016 at 8:23 AM, Eric Noulard 
>> wrote:
>>
>>>
>>>
>>> 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser 
>>> :
>>>
 On 08.11.2016 15:22 Nils Gladitz wrote:

> On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote:
>
> But how do you know which version to declare on cmake_minimum_required?
>> If this feature will be added it won't be far from writing a script
>> that scans the commands you use and outputs the first appropriate
>> version.
>>
>
 I'd also like such an addition to the documentation for reasons
 discussed below.
>>>
>>>
>>>
>>> I think the need is recognized by most CMake user but...
>>>
>>>


 Strictly speaking cmake_minimum_required(VERSION) is not about command
> availability but rather about behavior (cmake policies).
>
 [...]

> I'd start by requesting the highest possible version I could justify
> (e.g. based on availability on target platforms and user convenience)
> and then start from there.
>

 And that's exactly the (my) point. How can I find out the "highest
 possible version I could justify"?

 I'm a developer of a public GUI library (FLTK). In this position you
 don't know anything about the availability of CMake versions on your target
 platforms. Our intention is to keep cmake_minimum_required() as low as
 possible.

 That said, whenever you change a CMakeLists.txt file you should be
 aware if the commands you use are compatible with the CMake version you
 "require". There should be an easy way to find out in which version a
 particular CMake command has been introduced. Only with this information
 you can decide if you should use this fine command or better find another
 way to do the task you're going to do.

 I'd like to have a list of release dates (I'm not sure if there is one)
 as well as the exact version a 

Re: [CMake] Adding Cmake version in online documentation

[Jakob van Bethlehem]

+1 for me too - sometime ago a college of mine spend quite some time to
figure why he couldn't bootstrap our application - turns out he was using
an (old) CMake version which didn't know about the 'continue' command. The
error-messages coming out of CMake sometimes help, but more often don't
really give the correct hint, unless you happen to be one of the local
CMake gurus.

Sincerely,
Jakob


On Tue, Nov 8, 2016 at 10:33 PM, Craig Scott 
wrote:

> Rather than trying to do everything, perhaps there's value in tackling
> this in stages. At a high level, simply knowing in which CMake version a
> particular command, property, variable or module was added is a good start.
> From there, if a command, etc. gained new options, then a note could be
> added with the text specific to that option to indicate when it was added.
> Obviously the more fine grained you go, the more time consuming and onerous
> it would become, but how about just starting with the coarse level? That
> already provides a big improvement over the current alternative of wading
> through past versions of documentation and/or source code.
>
> I'd also recommend that such version details be part of the actual CMake
> docs. While the separate compatibility matrix on the wiki is/was a useful
> resource, by not having it part of the CMake sources/docs, it is inherently
> a separate effort to try to keep it up to date with each CMake release.
> Making it part of CMake itself would seem to encourage documenting version
> details as part of the same merge requests, etc. that add/change things.
>
> I'll go out on a limb here and suggest that if a clear guideline was given
> for *how* version details should be documented, then the community itself
> would likely work towards populating that information over time. I don't
> think there is a (realistic) expectation that Kitware would do all the
> heavy lifting here.
>
>
>
> On Wed, Nov 9, 2016 at 8:23 AM, Eric Noulard 
> wrote:
>
>>
>>
>> 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser :
>>
>>> On 08.11.2016 15:22 Nils Gladitz wrote:
>>>
 On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote:

 But how do you know which version to declare on cmake_minimum_required?
> If this feature will be added it won't be far from writing a script
> that scans the commands you use and outputs the first appropriate
> version.
>

>>> I'd also like such an addition to the documentation for reasons
>>> discussed below.
>>
>>
>>
>> I think the need is recognized by most CMake user but...
>>
>>
>>>
>>>
>>> Strictly speaking cmake_minimum_required(VERSION) is not about command
 availability but rather about behavior (cmake policies).

>>> [...]
>>>
 I'd start by requesting the highest possible version I could justify
 (e.g. based on availability on target platforms and user convenience)
 and then start from there.

>>>
>>> And that's exactly the (my) point. How can I find out the "highest
>>> possible version I could justify"?
>>>
>>> I'm a developer of a public GUI library (FLTK). In this position you
>>> don't know anything about the availability of CMake versions on your target
>>> platforms. Our intention is to keep cmake_minimum_required() as low as
>>> possible.
>>>
>>> That said, whenever you change a CMakeLists.txt file you should be aware
>>> if the commands you use are compatible with the CMake version you
>>> "require". There should be an easy way to find out in which version a
>>> particular CMake command has been introduced. Only with this information
>>> you can decide if you should use this fine command or better find another
>>> way to do the task you're going to do.
>>>
>>> I'd like to have a list of release dates (I'm not sure if there is one)
>>> as well as the exact version a feature was introduced to write
>>> CMakeLists.txt files that run on really old CMake versions
>>
>>
>> Some time ago people came up (dig the ML for the related discussion) with
>> compatibility matrix idea:
>> https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix
>> http://public.kitware.com/pipermail/cmake/2010-December/041202.html
>>
>> And it finally ends with cmake 3.0.0
>> http://public.kitware.com/pipermail/cmake/2015-March/059983.html
>>
>> Note that this is far more complicated than simply listing when one
>> command appears because some command may get more options, or change their
>> default semantic
>> (using POLICY etc..) so the feature granularity leads to question like
>>
>> When did the 'string' cmake command support the UUID argument ?
>>
>> Before which version of CMake does get_target_property
>> accept  non-existent target argument without issuing any error or warning ?
>> (see POLICY CMP0045)
>>
>> So basically, tracking all kind of behavior change is not as easy as it
>> seems.
>>
>> How can we document the changes ? Or better extract them from the code or
>> documentation?
>>
>> --
>> Eric

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 12:04, Ruslan Baratov wrote:

On 09-Nov-16 16:22, Nils Gladitz wrote:

On 09.11.2016 04:29, Ruslan Baratov wrote:

On 08-Nov-16 23:33, Nils Gladitz wrote:

On 11/08/2016 04:17 PM, Ruslan Baratov wrote:


Except it's exactly opposite :) `cmake_minimum_required` is about new
features/commands, and policies is about behavior.


I don't agree and you can not separate the two.
cmake_minimum_required() initializes the policies based on the 
given version.
So what? From the user's perspective the "initialization of 
policies" is like a syntactic sugar so you don't have to write 
endless `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal 
with them further.


You can't simultaneously argue that cmake_minimum_required() isn't 
about policies (behaviours) and at the same time syntactic sugar for 
those very same policies.

You're playing with words instead of using arguments.


There was no word play involved.
You say cmake_minimum_required() is not about behaviour yet it 
initializes all policies which are purely about behaviour.






Policy warnings aren't meant to indicate errors in your code but 
changes in behaviour that will happen if you were to increase your 
minimum required version.
Policy CMP0038 doesn't agree with you: 
https://cmake.org/cmake/help/latest/policy/CMP0038.html


No policies are still primarily about behaviour changes. That is true 
for CMP0038 as well.


The old behaviour is to ignore this issue in user code. The new 
behaviour is to produce an error.
When maintainers get this warning they are informed that their code will 
break as soon as they increase their minimum required version.


The same is true for CMP0054. The policy warning did find many errors in 
user code but the warning is primarily about the change in behaviour.



Yes, like this:

cmake_minimum_required(VERSION  2.8)
project(foo)

if(POLICY CMP0038)cmake_policy(SET CMP0038 OLD) endif()

Now CMake 3.0 users will not see the warning and CMake 2.8 users 
**don't have to upgrade**.


Yes but I don't see what point you are trying to make ... they didn't 
have to upgrade without the explicit policy set either.
And the policy warnings aren't meant for users they are meant for 
maintainers.



In fact all that setting it to OLD does is suppress the warning.

Actually this statement is wrong. Take a look at this example:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(fooVERSION 1.2.3)
cmake_policy(SET CMP0038 OLD) # Do not remove this!
add_library(foofoo.cpp)
target_link_libraries(foofoo)

if you remove `cmake_policy(SET CMP0038 OLD)` this example will 
produce **error**. It may happens when you want to use new **feature** 
`project(VERSION)` from 3.0, hence you set 
`cmake_minimum_required(VERSION 3.0)` and simultaneously you have code 
which produce warning about CMP0038. By setting `cmake_policy(SET 
CMP0038 OLD)` you suppress the error, i.e. change **behaviour**.


You took this out of context. I was talking about your second example 
about CMP0054 which was unset by cmake_minimum_required(VERSION 2.8) and 
then explicitly set to OLD by you.
In this new case you have a policy that is initialized to NEW by 
cmake_minimum_required(VERSION 3.0) and then set to OLD by you.


Policies are not meant to be feature toggles. You are explicitly asking 
CMake to use deprecated behaviour (that should no longer be used and 
might be removed in the future) over new behaviour.




It's better than emitting zillion of warnings to the output, right? 
You can suppress one type and fix another, set TODOs, etc.


Policy warnings are intended to encourage you to switch to new 
behaviours since the old ones are deprecated.

In actively maintained projects they are not meant to be suppressed.
Why not? If you're not planning to fix them right now? I'm not saying 
you have to ignore them, you have to do fixes, but why not suppress 
and say work on other fixes?


Like I said policies are not primarily about fixing code. They are about 
migrating to new behaviours introduced by new versions of CMake.




And this code will produce "FOO":

cmake_minimum_required(VERSION 3.1)

cmake_policy(SET CMP0054 OLD) # behave like 3.0

set(ONE 1)

if(1 STREQUAL "ONE")
  message("FOO")
else()
  message("BAR")
endif()

In this example by `cmake_minimum_required(VERSION 3.1)` you telling 
user that you're planning to use some **feature** from CMake 3.1. 


Again I disagree. cmake_minimum_required(VERSION 3.1) tells CMake to 
behave like 3.1. It does not indicate that you want to use any 3.1 
specific features.


This feature may be about interpreting differently `if(1 STREQUAL 
"ONE")` and `if(1 STREQUAL ONE)` or may be about anything else. Note 
that CMake 3.0 **has no such feature** and commands  `if(1 STREQUAL 
"ONE")` /`if(1 STREQUAL ONE)` is same for him always. Policy CMP0054 
is about **behaviour**: "how we really should interpret `if(1 STREQUAL 
"ONE")`"? 

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

On 09-Nov-16 16:22, Nils Gladitz wrote:
> On 09.11.2016 03:47, Ruslan Baratov wrote:
>> On 09-Nov-16 06:01, Nils Gladitz wrote:
>>> I think the git tag creation dates should roughly equate release dates:
>>>  https://cmake.org/gitweb?p=cmake.git;a=tags
>> What about the future releases? There was a page
>> https://cmake.org/Bug/changelog_page.php before but it's no longer valid
>> as far as I understand.
>
> https://gitlab.kitware.com/cmake/cmake/milestones
>
> I wouldn't consider those dates to be anything but very rough
> estimates though.
>
> Nils

Ok, thanks. At least something :)

Ruslo

-- 

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 Cmake version in online documentation

[Ruslan Baratov via CMake]

On 09-Nov-16 16:22, Nils Gladitz wrote:
> On 09.11.2016 04:29, Ruslan Baratov wrote:
>> On 08-Nov-16 23:33, Nils Gladitz wrote:
>>> On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
>>>
 Except it's exactly opposite :) `cmake_minimum_required` is about new
 features/commands, and policies is about behavior.
>>>
>>> I don't agree and you can not separate the two.
>>> cmake_minimum_required() initializes the policies based on the given
>>> version.
>> So what? From the user's perspective the "initialization of policies"
>> is like a syntactic sugar so you don't have to write endless
>> `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal with them
>> further.
>
> You can't simultaneously argue that cmake_minimum_required() isn't
> about policies (behaviours) and at the same time syntactic sugar for
> those very same policies.
You're playing with words instead of using arguments.

>
>>
>>>
   If you have command
 `if(IN_LIST)` since 3.3 you can't manipulate policies in such way that
 it will work with CMake 2.8. However if you have warning about policy
 CMP0054 (since CMake 3.2) you can set policy to old without changing
 `cmake_minimum_required` (hence without forcing your CMake 2.8
 users to
 upgrade to CMake 3.2).
>>>
>>> Coincidentally I implemented both of those policies :)
>>>
>>> Given your second example you likely shouldn't be touching the
>>> policy at all.
>> I have to. If my code use features from CMake 2.8 I do set
>> `cmake_minimum_required(VERSION 2.8)`. But some users may have CMake
>> 3.2 installed. Do they must downgrade CMake? Of course not. But if
>> I'm not touching policies there will be warnings around. If I'm good
>> developer I will investigate the root of the warnings and fix them.
>> Actually most of them will be about bugs in my code or dangerous
>> behavior, so it does improve 2.8 too.
>
> Policy warnings aren't meant to indicate errors in your code but
> changes in behaviour that will happen if you were to increase your
> minimum required version.
Policy CMP0038 doesn't agree with you:
https://cmake.org/cmake/help/latest/policy/CMP0038.html

> As such they can often be worked around by using behaviour that is
> consistent between versions but they are not meant to indicate errors
> to be fixed.
>
> Instead they are meant to encourage you to embrace the new behaviours
> and abandon the old (which will require porting work) since the old
> are by definition deprecated and may be removed in the future (though
> so far CMake has been very conservative about this).
>
>>
>>>
>>> A policy warning does not force your users to use a new CMake version.
>> Well that's what I said.
>
> You said you are not forcing your users to upgrade by setting a policy
> to OLD.
Yes, like this:

cmake_minimum_required(VERSION 2.8)
project(foo)

if(POLICY CMP0038)cmake_policy(SET CMP0038 OLD) endif()

Now CMake 3.0 users will not see the warning and CMake 2.8 users **don't
have to upgrade**.

> Which implied that not setting the policy to OLD would force your
> users to upgrade ... which it doesn't.
No, it doesn't imply this :) Not setting policy to OLD in this case
produce warnings that I have to deal with.

>
>>
>>> In fact all that setting it to OLD does is suppress the warning.
Actually this statement is wrong. Take a look at this example:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(fooVERSION 1.2.3)
cmake_policy(SET CMP0038 OLD) # Do not remove this!
add_library(foofoo.cpp)
target_link_libraries(foofoo)

if you remove `cmake_policy(SET CMP0038 OLD)` this example will produce
**error**. It may happens when you want to use new **feature**
`project(VERSION)` from 3.0, hence you set
`cmake_minimum_required(VERSION 3.0)` and simultaneously you have code
which produce warning about CMP0038. By setting `cmake_policy(SET
CMP0038 OLD)` you suppress the error, i.e. change **behaviour**.

>> It's better than emitting zillion of warnings to the output, right?
>> You can suppress one type and fix another, set TODOs, etc.
>
> Policy warnings are intended to encourage you to switch to new
> behaviours since the old ones are deprecated.
> In actively maintained projects they are not meant to be suppressed.
Why not? If you're not planning to fix them right now? I'm not saying
you have to ignore them, you have to do fixes, but why not suppress and
say work on other fixes?

>
>>
>>> CMake will use the old behavior in either case.
>>>
>>> The warnings guide developers when they do bump their
>>> cmake_minimum_required(VERSION).
>>> By just suppressing it behavior changes might go unnoticed when the
>>> bump does happen.
>> There are 3 components in the equation: the **real** CMake version,
>> the version in `cmake_minimum_required` and the default policies for
>> such version. Can you provide an example of what you mean?
>
> cmake_minimum_required(VERSION 3.0)
>
> set(ONE 1)
>
> if(1 STREQUAL "ONE")
> 

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 03:47, Ruslan Baratov wrote:

On 09-Nov-16 06:01, Nils Gladitz wrote:

I think the git tag creation dates should roughly equate release dates:
 https://cmake.org/gitweb?p=cmake.git;a=tags

What about the future releases? There was a page
https://cmake.org/Bug/changelog_page.php before but it's no longer valid
as far as I understand.


https://gitlab.kitware.com/cmake/cmake/milestones

I wouldn't consider those dates to be anything but very rough estimates 
though.


Nils
--

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 Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 04:29, Ruslan Baratov wrote:

On 08-Nov-16 23:33, Nils Gladitz wrote:

On 11/08/2016 04:17 PM, Ruslan Baratov wrote:


Except it's exactly opposite :) `cmake_minimum_required` is about new
features/commands, and policies is about behavior.


I don't agree and you can not separate the two.
cmake_minimum_required() initializes the policies based on the given 
version.
So what? From the user's perspective the "initialization of policies" 
is like a syntactic sugar so you don't have to write endless 
`cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal with them 
further.


You can't simultaneously argue that cmake_minimum_required() isn't about 
policies (behaviours) and at the same time syntactic sugar for those 
very same policies.







  If you have command
`if(IN_LIST)` since 3.3 you can't manipulate policies in such way that
it will work with CMake 2.8. However if you have warning about policy
CMP0054 (since CMake 3.2) you can set policy to old without changing
`cmake_minimum_required` (hence without forcing your CMake 2.8 users to
upgrade to CMake 3.2).


Coincidentally I implemented both of those policies :)

Given your second example you likely shouldn't be touching the policy 
at all.
I have to. If my code use features from CMake 2.8 I do set 
`cmake_minimum_required(VERSION 2.8)`. But some users may have CMake 
3.2 installed. Do they must downgrade CMake? Of course not. But if I'm 
not touching policies there will be warnings around. If I'm good 
developer I will investigate the root of the warnings and fix them. 
Actually most of them will be about bugs in my code or dangerous 
behavior, so it does improve 2.8 too.


Policy warnings aren't meant to indicate errors in your code but changes 
in behaviour that will happen if you were to increase your minimum 
required version.
As such they can often be worked around by using behaviour that is 
consistent between versions but they are not meant to indicate errors to 
be fixed.


Instead they are meant to encourage you to embrace the new behaviours 
and abandon the old (which will require porting work) since the old are 
by definition deprecated and may be removed in the future (though so far 
CMake has been very conservative about this).






A policy warning does not force your users to use a new CMake version.

Well that's what I said.


You said you are not forcing your users to upgrade by setting a policy 
to OLD.
Which implied that not setting the policy to OLD would force your users 
to upgrade ... which it doesn't.





In fact all that setting it to OLD does is suppress the warning.
It's better than emitting zillion of warnings to the output, right? 
You can suppress one type and fix another, set TODOs, etc.


Policy warnings are intended to encourage you to switch to new 
behaviours since the old ones are deprecated.

In actively maintained projects they are not meant to be suppressed.




CMake will use the old behavior in either case.

The warnings guide developers when they do bump their 
cmake_minimum_required(VERSION).
By just suppressing it behavior changes might go unnoticed when the 
bump does happen.
There are 3 components in the equation: the **real** CMake version, 
the version in `cmake_minimum_required` and the default policies for 
such version. Can you provide an example of what you mean?


cmake_minimum_required(VERSION 3.0)

set(ONE 1)

if(1 STREQUAL "ONE")
message("FOO")
else()
message("BAR")
endif()

This code was designed for 3.0 (as indicated by the 
cmake_minimum_required(VERSION)) and is meant to output "FOO".

When you use CMake 3.0 that is the behaviour you get (without warnings).
When you use CMake >= 3.1 the behaviour of the code itself is still the 
same but you will get a CMP0054 warning telling you that the behaviour 
that you currently depend on in if() has been deprecated.


Now you decide to bump your minimum required version from 3.0 to 3.1 and 
ignore or suppress the policy warning from before:


cmake_minimum_required(VERSION 3.1)

set(ONE 1)

if(1 STREQUAL "ONE")
message("FOO")
else()
message("BAR)
endif()

Now when you use CMake >= 3.1 to run this code you will not get any more 
warnings but it will also no longer behave like it used to.


It will output "BAR" instead of "FOO".


Nils

-- 

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