[Cmake-commits] CMake branch, master, updated. v3.7.0-rc3-445-g25085f4

[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  25085f41b20f7f5a5fb25e8ab683f77476f917a2 (commit)
  from  666bb0e3fa0d212c03f785bd9f6bc05d29925e1f (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=25085f41b20f7f5a5fb25e8ab683f77476f917a2
commit 25085f41b20f7f5a5fb25e8ab683f77476f917a2
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Nov 9 00:01:04 2016 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Nov 9 00:01:04 2016 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 817af3b..b1549a1 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 20161108)
+set(CMake_VERSION_PATCH 20161109)
 #set(CMake_VERSION_RC 1)

---

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


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

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

On 08-Nov-16 23:33, Nils Gladitz wrote:
> On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
>
>> On 08-Nov-16 22:22, Nils Gladitz wrote:
>>> Strictly speaking cmake_minimum_required(VERSION) is not about command
>>> availability but rather about behavior (cmake policies).
>> 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.

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

>
> A policy warning does not force your users to use a new CMake version.
Well that's what I said.

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

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

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 06:01, Nils Gladitz wrote:
> On 08.11.2016 20:26, Albrecht Schlosser wrote:
>
>>
>> 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.
>>
>
> 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.

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

[Albrecht Schlosser]

On 08.11.2016 23:01 Nils Gladitz wrote:

On 08.11.2016 20:26, Albrecht Schlosser wrote:


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.



If you are intending to keep the required version as low as possible
you'll already have a justification / reason for doing so.
I can only assume that the reason is that you need to support ancient
platforms which ship equally ancient versions of CMake and you don't
want to bother your users to build or install custom newer versions of
CMake.

It doesn't matter what your reasons or justifications for it are (though
I would hope they are valid and verified) but you have to decide on a
minimum version that you can life with in the end.


Basically that's a floating target. We need to evaluate this from time 
to time and maybe adjust the required version.



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.


At this point you only have to refer to the documentation that actually
corresponds to the version you decided to require.
You'll only find commands and behaviours in that documentation that'll
actually be available in your minimum version.


Yep, that's simple, of course. But if there is a (new) command you want 
to use it would be interesting to know the CMake version it was 
introduced to _decide_ if you can or want to do without it or raise the 
required version. I'm sure that we will raise the required version when 
CMake gets (or got) a new feature we need to use. But we need the facts 
to decide...



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.



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


Thanks for this, I appreciate your help.


Note: currently we have cmake_minimum_required(VERSION 2.6.3) (sic!),
but we also have conditional code for some higher CMake versions:


2.6.3's tag e.g. "Sat, 21 Feb 2009 19:43:45 + (14:43 -0500)" would
be over 7 years old now.


As I said: this is a floating target. Since this version is so old we 
may decide to require a more recent version in the near future, but 
likely not yet 3.7 ;-)



if(CMAKE_VERSION VERSION_GREATER 2.8.4) ...
if(NOT CMAKE_VERSION VERSION_LESS 3.0.0) ...


There are exceptions to every rule but I'd personally avoid or at least
try to minimize such constructs if possible.


I think these two are the only special cases, and they are used for new 
features we use if available with a fallback (or not at all) if the 
CMake version is older.



CMake's policy mechanism tries hard to preserve old behaviours so that
existing projects depending on those old behaviours don't break with new
versions of CMake.
Given your minimum required version CMake 3.7 will still mostly try to
behave like 2.6.3.


I'm not very familiar with CMake policies. Maybe I need some more RTFM.


With constructs like these this is no longer the case and you need an
increasing number of CMake versions to get proper coverage.
Developers that use one specific version of CMake can not longer be
reasonably confident that their CMake script changes also work on other
versions of CMake covered by distinct version specific conditionals.


Good point, thanks for this as well. But as I said before, these 
constructs are only exceptions.


BTW: Thanks to all CMake devs for this great tool!

--

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

[Albrecht Schlosser]

On 08.11.2016 22:23 Eric Noulard wrote:


2016-11-08 20:26 GMT+01:00 Albrecht Schlosser <...>:

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


okay...


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.


Sure, I agree. Thanks for your elaborate comments.


How can we document the changes ? Or better extract them from the code
or documentation?


A simple comment like "since 3.5.0" for the _first_ appearance of a 
command would be very helpful. Added keywords could be commented as well.


I see that behavior changes would be more difficult to document, but 
documentation of policies seem to do a good job in their particular cases.


--

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

[Tiago Macarios]

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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 08.11.2016 20:26, Albrecht Schlosser wrote:

On 08.11.2016 15:22 Nils Gladitz wrote:


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.




If you are intending to keep the required version as low as possible 
you'll already have a justification / reason for doing so.
I can only assume that the reason is that you need to support ancient 
platforms which ship equally ancient versions of CMake and you don't 
want to bother your users to build or install custom newer versions of 
CMake.


It doesn't matter what your reasons or justifications for it are (though 
I would hope they are valid and verified) but you have to decide on a 
minimum version that you can life with in the end.


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.


At this point you only have to refer to the documentation that actually 
corresponds to the version you decided to require.
You'll only find commands and behaviours in that documentation that'll 
actually be available in your minimum version.
You will not find commands or behaviours that are unavailable in your 
version so you will not be tempted to use them nor will you have to 
asses them individually for their availability.




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.




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

Note: currently we have cmake_minimum_required(VERSION 2.6.3) (sic!), 
but we also have conditional code for some higher CMake versions:


2.6.3's tag e.g. "Sat, 21 Feb 2009 19:43:45 + (14:43 -0500)" would 
be over 7 years old now.




if(CMAKE_VERSION VERSION_GREATER 2.8.4) ...
if(NOT CMAKE_VERSION VERSION_LESS 3.0.0) ...



There are exceptions to every rule but I'd personally avoid or at least 
try to minimize such constructs if possible.


CMake's policy mechanism tries hard to preserve old behaviours so that 
existing projects depending on those old behaviours don't break with new 
versions of CMake.
Given your minimum required version CMake 3.7 will still mostly try to 
behave like 2.6.3.


With constructs like these this is no longer the case and you need an 
increasing number of CMake versions to get proper coverage.
Developers that use one specific version of CMake can not longer be 
reasonably confident that their CMake script changes also work on other 
versions of CMake covered by distinct version specific conditionals.


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

[Craig Scott]

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

Re: [CMake] Adding Cmake version in online documentation

[Eric Noulard]

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

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

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



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.


Note: currently we have cmake_minimum_required(VERSION 2.6.3) (sic!), 
but we also have conditional code for some higher CMake versions:


if(CMAKE_VERSION VERSION_GREATER 2.8.4) ...
if(NOT CMAKE_VERSION VERSION_LESS 3.0.0) ...

I'd appreciate such additions very much to be able to write more 
portable CMake files. TIA.


--

Powered by www.kitware.com

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

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

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

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

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

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

[Brad King]

On 11/08/2016 02:16 PM, Robert Goulet wrote:
> +  if (cmSystemToolsCMakeRoot.empty()) {
> +std::string dir = cmSystemTools::GetFilenamePath(exe_dir);

Please see my sibling response for why more logic is needed.

-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] cmake 3.7.0-rc3 regression

[Robert Goulet]

Anyhow, here's a quick patch that fixes it.

Thanks.

-Original Message-
From: Robert Goulet 
Sent: Tuesday, November 8, 2016 2:09 PM
To: 'Rolf Eike Beer' ; cmake-developers@cmake.org
Subject: RE: [cmake-developers] cmake 3.7.0-rc3 regression

Not sure I understand why is this part of a build switch now? And what if we 
don't build CMake ourselves but instead, using prebuilt binaries from the CMake 
website?

-Original Message-
From: Rolf Eike Beer [mailto:e...@sf-mail.de]
Sent: Tuesday, November 8, 2016 2:04 PM
To: cmake-developers@cmake.org
Cc: Robert Goulet 
Subject: Re: [cmake-developers] cmake 3.7.0-rc3 regression

Am Dienstag, 8. November 2016, 18:59:34 schrieb Robert Goulet:
> Hi,
> 
> After trying to upgrade to CMake 3.7.0-rc3, we've found the following
> regression:
> 
> Previously, we were able to put multiple platform CMake executables in 
> the same root by just renaming the "bin" folder, so that they don't 
> overlap each other, as such:
> 
> cmake/win/cmake.exe
> cmake/mac/cmake
> cmake/linux/cmake
> cmake/share/...
> cmake/doc/...
> 
> However in 3.7.0-rc3 this is broken, no longer works if the CMake 
> binary folder isn't named specifically "bin". CMake will fail to 
> start, reporting "CMake Error: Could not find CMAKE_ROOT !!!".
> 
> Traced it back to this commit:
> 
> Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b
> 
> Add option to control 'bin' directory of CMake's own installation
> (#16076)
> 
> Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration.
> Add a `--bindir` option to the `bootstrap` script to set it.
> 
> If this wasn't intentional, can we get a fix before 3.7.0 is released?

If you read the commit message you should be able to fix your problem: just 
build the different CMake instances with different --bindir switches.

Eike


0001-Fix-CMake-regression-unable-to-locate-cmake-root-dir.patch
Description: 0001-Fix-CMake-regression-unable-to-locate-cmake-root-dir.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Brad King]

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-developers] cmake 3.7.0-rc3 regression

[Rolf Eike Beer]

Am Dienstag, 8. November 2016, 18:59:34 schrieb Robert Goulet:
> Hi,
> 
> After trying to upgrade to CMake 3.7.0-rc3, we've found the following
> regression:
> 
> Previously, we were able to put multiple platform CMake executables in the
> same root by just renaming the "bin" folder, so that they don't overlap
> each other, as such:
> 
> cmake/win/cmake.exe
> cmake/mac/cmake
> cmake/linux/cmake
> cmake/share/...
> cmake/doc/...
> 
> However in 3.7.0-rc3 this is broken, no longer works if the CMake binary
> folder isn't named specifically "bin". CMake will fail to start, reporting
> "CMake Error: Could not find CMAKE_ROOT !!!".
> 
> Traced it back to this commit:
> 
> Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b
> 
> Add option to control 'bin' directory of CMake's own installation
> (#16076)
> 
> Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration.
> Add a `--bindir` option to the `bootstrap` script to set it.
> 
> If this wasn't intentional, can we get a fix before 3.7.0 is released?

If you read the commit message you should be able to fix your problem: just 
build the different CMake instances with different --bindir switches.

Eike

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

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

[Robert Goulet]

Not sure I understand why is this part of a build switch now? And what if we 
don't build CMake ourselves but instead, using prebuilt binaries from the CMake 
website?

-Original Message-
From: Rolf Eike Beer [mailto:e...@sf-mail.de] 
Sent: Tuesday, November 8, 2016 2:04 PM
To: cmake-developers@cmake.org
Cc: Robert Goulet 
Subject: Re: [cmake-developers] cmake 3.7.0-rc3 regression

Am Dienstag, 8. November 2016, 18:59:34 schrieb Robert Goulet:
> Hi,
> 
> After trying to upgrade to CMake 3.7.0-rc3, we've found the following
> regression:
> 
> Previously, we were able to put multiple platform CMake executables in 
> the same root by just renaming the "bin" folder, so that they don't 
> overlap each other, as such:
> 
> cmake/win/cmake.exe
> cmake/mac/cmake
> cmake/linux/cmake
> cmake/share/...
> cmake/doc/...
> 
> However in 3.7.0-rc3 this is broken, no longer works if the CMake 
> binary folder isn't named specifically "bin". CMake will fail to 
> start, reporting "CMake Error: Could not find CMAKE_ROOT !!!".
> 
> Traced it back to this commit:
> 
> Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b
> 
> Add option to control 'bin' directory of CMake's own installation
> (#16076)
> 
> Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration.
> Add a `--bindir` option to the `bootstrap` script to set it.
> 
> If this wasn't intentional, can we get a fix before 3.7.0 is released?

If you read the commit message you should be able to fix your problem: just 
build the different CMake instances with different --bindir switches.

Eike
-- 

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-983-g9b7016e

[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  9b7016eea420f6eec2e016d2f694c58eea3e4bbd (commit)
   via  e9636dafb2e11b0df9da1841981514578e2659ca (commit)
  from  3cc9809f374ea224a24d145b85a3af8cffb4c2fd (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=9b7016eea420f6eec2e016d2f694c58eea3e4bbd
commit 9b7016eea420f6eec2e016d2f694c58eea3e4bbd
Merge: 3cc9809 e9636da
Author: Brad King 
AuthorDate: Tue Nov 8 14:03:00 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 14:03:00 2016 -0500

Merge topic 'imported-interface-libname' into next

e9636daf fixup! Allow imported INTERFACE libraries to specify a link 
library name


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e9636dafb2e11b0df9da1841981514578e2659ca
commit e9636dafb2e11b0df9da1841981514578e2659ca
Author: Brad King 
AuthorDate: Tue Nov 8 14:02:42 2016 -0500
Commit: Brad King 
CommitDate: Tue Nov 8 14:02:42 2016 -0500

fixup! Allow imported INTERFACE libraries to specify a link library name

diff --git a/Source/cmComputeLinkInformation.cxx 
b/Source/cmComputeLinkInformation.cxx
index ff386f9..80e7e7d 100644
--- a/Source/cmComputeLinkInformation.cxx
+++ b/Source/cmComputeLinkInformation.cxx
@@ -610,7 +610,7 @@ void cmComputeLinkInformation::AddItem(std::string const& 
item,
   // Also add the item the interface specifies to be used in its place.
   std::string const& libName = tgt->GetImportedLibName(config);
   if (!libName.empty()) {
-this->AddItem(libName, 0);
+this->AddItem(libName, CM_NULLPTR);
   }
 } else {
   // Decide whether to use an import library.

---

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


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

Re: [CMake] Force MSVC runtime for debug builds

[Michael Jackson]

I would agree. I don't know how many subtle runtime bugs I have had to 
figure out because our project mixed debug and release runtimes on MSVC. 
DON'T do it unless you REALLY have to. But even then I would never 
actually deploy that into production.


YMMV
--
Mike Jackson  [mike.jack...@bluequartz.net]


clin...@elemtech.com wrote:



- On Nov 7, 2016, at 1:37 AM, Stephan Menzel
 wrote:

Hello everyone,
I'm looking for a way to force Debug configurations in generated
MSVC solutions to use the Release runtime instead of the default
"Debug". e.g. /MD rather than /MDd.

My use case is an ever recurring problem of creating libraries that
are linked in plug-in fashion against Release only applications. I
want for my Debug configuration to have debug info and no
optimization but still use the release runtime so I can link them.

I tried replacing /MDd with /MD in CMAKE_CXX_FLAGS_DEBUG. This
yielded objects built with /MD alright but failed to link into an
executable with stuff like that:

error LNK2038: mismatch detected for 'RuntimeLibrary': value
'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in Test.obj

 From what I gather all the obj are actually compiled for Release
runtime without optimization and Debug info just like I need it. But
then the main obj is built and linked in Debug mode, causing the
executable to not be created.

Is there a way to solve this? Like a generic CMake executable flag
or something that I can use to force the other runtime?

Please note that using RelWithDebInfo and turning off optimization
is not exactly what I need as I still want that mode much the way it is.

If you are going to use /MD instead of /MDd, then you probably also need
to remove the _DEBUG preprocessor flag.
IIRC, I've seen cases where defining _DEBUG includes symbols only
defined by the debug runtimes.

Clint


--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] cmake 3.7.0-rc3 regression

[Robert Goulet]

Hi,

After trying to upgrade to CMake 3.7.0-rc3, we've found the following 
regression:

Previously, we were able to put multiple platform CMake executables in the same 
root by just renaming the "bin" folder, so that they don't overlap each other, 
as such:

cmake/win/cmake.exe
cmake/mac/cmake
cmake/linux/cmake
cmake/share/...
cmake/doc/...

However in 3.7.0-rc3 this is broken, no longer works if the CMake binary folder 
isn't named specifically "bin". CMake will fail to start, reporting "CMake 
Error: Could not find CMAKE_ROOT !!!".

Traced it back to this commit:

Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b

Add option to control 'bin' directory of CMake's own installation (#16076)

Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration.
Add a `--bindir` option to the `bootstrap` script to set it.

If this wasn't intentional, can we get a fix before 3.7.0 is released?

Thanks!
-- 

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] additional arguments with CMAKE_CXX_CLANG_TIDY variable

[Michael Ellery]

> On Nov 8, 2016, at 10:06 AM, Bill Hoffman  wrote:
> 
> On 11/8/2016 11:20 AM, Michael Ellery wrote:
>> /usr/local/Cellar/cmake/3.6.2/bin/cmake -E __run_iwyu
>> --tidy="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*"
>> --source=/Users/ellery/work/.
> That should still work.  It is passing that to -E __run_iwyu which should 
> expand the arguments.
> 
> https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmcmd.cxx#L353
> cmSystemTools::ExpandListArgument will separate out the arguments.  My guess 
> is the * might be causing the trouble somehow.
> 
> -Bill
> 
> 

Thanks - a quick test using `checks=google-runtime-memset`  (for example) does 
NOT fail, so your speculation about * causing issues seems pretty likely. I’m 
not sure if this is a bug or if there is some other workaround for special arg 
characters...

-- 

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] additional arguments with CMAKE_CXX_CLANG_TIDY variable

[Bill Hoffman]

On 11/8/2016 11:20 AM, Michael Ellery wrote:

/usr/local/Cellar/cmake/3.6.2/bin/cmake -E __run_iwyu
--tidy="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*"
--source=/Users/ellery/work/.
That should still work.  It is passing that to -E __run_iwyu which 
should expand the arguments.


https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmcmd.cxx#L353
cmSystemTools::ExpandListArgument will separate out the arguments.  My 
guess is the * might be causing the trouble somehow.


-Bill


--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Force MSVC runtime for debug builds

[clinton]

- On Nov 7, 2016, at 1:37 AM, Stephan Menzel  
wrote: 

> Hello everyone,
> I'm looking for a way to force Debug configurations in generated MSVC 
> solutions
> to use the Release runtime instead of the default "Debug". e.g. /MD rather 
> than
> /MDd.

> My use case is an ever recurring problem of creating libraries that are linked
> in plug-in fashion against Release only applications. I want for my Debug
> configuration to have debug info and no optimization but still use the release
> runtime so I can link them.

> I tried replacing /MDd with /MD in CMAKE_CXX_FLAGS_DEBUG. This yielded objects
> built with /MD alright but failed to link into an executable with stuff like
> that:

> error LNK2038: mismatch detected for 'RuntimeLibrary': value 
> 'MD_DynamicRelease'
> doesn't match value 'MDd_DynamicDebug' in Test.obj

> From what I gather all the obj are actually compiled for Release runtime 
> without
> optimization and Debug info just like I need it. But then the main obj is 
> built
> and linked in Debug mode, causing the executable to not be created.

> Is there a way to solve this? Like a generic CMake executable flag or 
> something
> that I can use to force the other runtime?

> Please note that using RelWithDebInfo and turning off optimization is not
> exactly what I need as I still want that mode much the way it is.

If you are going to use /MD instead of /MDd, then you probably also need to 
remove the _DEBUG preprocessor flag. 
IIRC, I've seen cases where defining _DEBUG includes symbols only defined by 
the debug runtimes. 

Clint 
-- 

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

[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  3cc9809f374ea224a24d145b85a3af8cffb4c2fd (commit)
   via  c807a70ac156634225b91300a0b1038229edeab4 (commit)
  from  0f1eae2d3d7bed2bcfde648e99150676c4cebe5b (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=3cc9809f374ea224a24d145b85a3af8cffb4c2fd
commit 3cc9809f374ea224a24d145b85a3af8cffb4c2fd
Merge: 0f1eae2 c807a70
Author: Brad King 
AuthorDate: Tue Nov 8 11:54:56 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 11:54:56 2016 -0500

Merge topic 'import-librhash' into next

c807a70a fixup! librhash: Remove source fragments not needed for CMake


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c807a70ac156634225b91300a0b1038229edeab4
commit c807a70ac156634225b91300a0b1038229edeab4
Author: Brad King 
AuthorDate: Tue Nov 8 11:54:46 2016 -0500
Commit: Brad King 
CommitDate: Tue Nov 8 11:54:46 2016 -0500

fixup! librhash: Remove source fragments not needed for CMake

diff --git a/Utilities/cmlibrhash/librhash/rhash.c 
b/Utilities/cmlibrhash/librhash/rhash.c
index 06a5da6..ad6249b 100644
--- a/Utilities/cmlibrhash/librhash/rhash.c
+++ b/Utilities/cmlibrhash/librhash/rhash.c
@@ -685,7 +685,6 @@ RHASH_API size_t rhash_print_magnet(char* output, const 
char* filepath,
 
return (output - begin);
 }
-#endif
 
 /* hash sum output */
 
@@ -870,3 +869,4 @@ RHASH_API rhash_uptr_t rhash_transmit(unsigned msg_id, 
void* dst, rhash_uptr_t l
}
return 0;
 }
+#endif

---

Summary of changes:
 Utilities/cmlibrhash/librhash/rhash.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-979-g0f1eae2

[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  0f1eae2d3d7bed2bcfde648e99150676c4cebe5b (commit)
   via  36f9f0f8a3e7640c12034fff8871b779cba9f0ce (commit)
  from  4e34731f14736e112ab6a0e40550d4ea9c6a3e80 (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=0f1eae2d3d7bed2bcfde648e99150676c4cebe5b
commit 0f1eae2d3d7bed2bcfde648e99150676c4cebe5b
Merge: 4e34731 36f9f0f
Author: Brad King 
AuthorDate: Tue Nov 8 11:44:15 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 11:44:15 2016 -0500

Merge topic 'drop-kwstyle' into next

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=36f9f0f8a3e7640c12034fff8871b779cba9f0ce
commit 36f9f0f8a3e7640c12034fff8871b779cba9f0ce
Author: Brad King 
AuthorDate: Tue Nov 8 11:40:20 2016 -0500
Commit: Brad King 
CommitDate: Tue Nov 8 11:40:20 2016 -0500

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

We now define code layout by clang-format and enforce whitespace with
Git hooks.  There is no need to run KWStyle anymore, as all we used it
to check was line length anyway.

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 5d72e5c..c0ffa46 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -3346,20 +3346,6 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
 --test-command InterfaceLinkLibraries)
   list(APPEND TEST_BUILD_DIRS 
"${CMake_BINARY_DIR}/Tests/InterfaceLinkLibraries")
 
-  if(CMAKE_USE_KWSTYLE AND KWSTYLE_EXECUTABLE)
-# The "make StyleCheck" command line as a test. If the test fails, look
-# for lines like "Error #0 (624) Line length exceed 88 (max=79)" in the
-# output to find where the style errors are...
-add_test(KWStyle ${KWSTYLE_EXECUTABLE}
-  -xml ${CMake_BINARY_DIR}/CMake.kws.xml
-  -o ${CMake_SOURCE_DIR}/Utilities/KWStyle/CMakeOverwrite.txt
-  -v
-  -D ${CMake_BINARY_DIR}/CMakeKWSFiles.txt
-  )
-set_tests_properties(KWStyle PROPERTIES
-  WORKING_DIRECTORY ${CMake_BINARY_DIR}/Utilities/KWStyle)
-  endif()
-
   if(NOT CMake_TEST_EXTERNAL_CMAKE)
 add_subdirectory(CMakeTests)
   endif()
diff --git a/Utilities/CMakeLists.txt b/Utilities/CMakeLists.txt
index 1e51ea2..014204b 100644
--- a/Utilities/CMakeLists.txt
+++ b/Utilities/CMakeLists.txt
@@ -1,7 +1,7 @@
 # Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
 # file Copyright.txt or https://cmake.org/licensing for details.
 
-subdirs(Doxygen KWStyle)
+subdirs(Doxygen)
 
 if(CMAKE_DOC_TARBALL)
   # Undocumented option to extract and install pre-built documentation.
diff --git a/Utilities/KWStyle/CMake.kws.xml.in 
b/Utilities/KWStyle/CMake.kws.xml.in
deleted file mode 100644
index c2b4429..000
--- a/Utilities/KWStyle/CMake.kws.xml.in
+++ /dev/null
@@ -1,11 +0,0 @@
-
-
-79
-
-
diff --git a/Utilities/KWStyle/CMakeFiles.txt.in 
b/Utilities/KWStyle/CMakeFiles.txt.in
deleted file mode 100644
index a95aac6..000
--- a/Utilities/KWStyle/CMakeFiles.txt.in
+++ /dev/null
@@ -1,15 +0,0 @@
-"@CMake_SOURCE_DIR@/Source/*.txx"
-"@CMake_SOURCE_DIR@/Source/*.cxx"
-"@CMake_SOURCE_DIR@/Source/*.h*"
-"@CMake_SOURCE_DIR@/Source/CPack/*.txx"
-"@CMake_SOURCE_DIR@/Source/CPack/*.cxx"
-"@CMake_SOURCE_DIR@/Source/CPack/*.h*"
-"@CMake_SOURCE_DIR@/Source/CTest/*.txx"
-"@CMake_SOURCE_DIR@/Source/CTest/*.cxx"
-"@CMake_SOURCE_DIR@/Source/CTest/*.h*"
-"@CMake_SOURCE_DIR@/Source/CurseDialog/*.h*"
-"@CMake_SOURCE_DIR@/Source/CurseDialog/*.cxx"
-"@CMake_SOURCE_DIR@/Source/CurseDialog/*.txx"
--f (Lexer\.h)
--f (Lexer\.cxx)
--f (Parser\.cxx)
diff --git a/Utilities/KWStyle/CMakeLists.txt b/Utilities/KWStyle/CMakeLists.txt
deleted file mode 100644
index 3e96c33..000
--- a/Utilities/KWStyle/CMakeLists.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-# Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
-# file Copyright.txt or https://cmake.org/licensing for details.
-
-#-
-# CMake uses KWStyle for checking the coding style
-
-# Search for a built-from-source KWStyle under Dashboards/Support on a typical
-# dashboard machines:
-#
-set(home "$ENV{HOME}")
-if(NOT home)
-  string(REPLACE "\\" "/" home "$ENV{USERPROFILE}")
-endif()
-
-find_program(KWSTYLE_EXECUTABLE
-  NAMES KWStyle
-  PATHS
-  "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Kitware Inc.\\KWStyle 1.0.0]/bin"
-  "${home}/Dashboards/Support/KWStyle/bin"

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-977-g4e34731

[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  4e34731f14736e112ab6a0e40550d4ea9c6a3e80 (commit)
   via  814a5d1548cf99dbb8ab4a40c3c7d05efac9bd1f (commit)
   via  4f9f9b5f079987385cf25fd2d51cb5d64d8f558c (commit)
  from  6b37f52ef8f55b687246c10e7eb72a894b429422 (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=4e34731f14736e112ab6a0e40550d4ea9c6a3e80
commit 4e34731f14736e112ab6a0e40550d4ea9c6a3e80
Merge: 6b37f52 814a5d1
Author: Brad King 
AuthorDate: Tue Nov 8 11:38:24 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 11:38:24 2016 -0500

Merge topic 'import-librhash' into next

814a5d15 librhash: Implement bswap_64 even in strict C90 mode
4f9f9b5f librhash: Use __builtin_bswap64 on Clang


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=814a5d1548cf99dbb8ab4a40c3c7d05efac9bd1f
commit 814a5d1548cf99dbb8ab4a40c3c7d05efac9bd1f
Author: Brad King 
AuthorDate: Tue Nov 8 11:33:09 2016 -0500
Commit: Brad King 
CommitDate: Tue Nov 8 11:36:36 2016 -0500

librhash: Implement bswap_64 even in strict C90 mode

diff --git a/Utilities/cmlibrhash/librhash/byte_order.h 
b/Utilities/cmlibrhash/librhash/byte_order.h
index 3178807..fe49e26 100644
--- a/Utilities/cmlibrhash/librhash/byte_order.h
+++ b/Utilities/cmlibrhash/librhash/byte_order.h
@@ -104,8 +104,8 @@ static inline uint32_t bswap_32(uint32_t x) {
 # define bswap_64(x) __builtin_bswap64(x)
 #elif (_MSC_VER > 1300) && (defined(CPU_IA32) || defined(CPU_X64)) /* MS VC */
 # define bswap_64(x) _byteswap_uint64((__int64)x)
-#elif !defined(__STRICT_ANSI__)
-static inline uint64_t bswap_64(uint64_t x) {
+#else
+static uint64_t bswap_64(uint64_t x) {
union {
uint64_t ll;
uint32_t l[2];
@@ -115,8 +115,6 @@ static inline uint64_t bswap_64(uint64_t x) {
r.l[1] = bswap_32(w.l[0]);
return r.ll;
 }
-#else
-#error "bswap_64 unsupported"
 #endif
 
 #ifdef CPU_BIG_ENDIAN

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f9f9b5f079987385cf25fd2d51cb5d64d8f558c
commit 4f9f9b5f079987385cf25fd2d51cb5d64d8f558c
Author: Brad King 
AuthorDate: Tue Nov 8 11:32:02 2016 -0500
Commit: Brad King 
CommitDate: Tue Nov 8 11:32:02 2016 -0500

librhash: Use __builtin_bswap64 on Clang

diff --git a/Utilities/cmlibrhash/librhash/byte_order.h 
b/Utilities/cmlibrhash/librhash/byte_order.h
index f9a0fb8..3178807 100644
--- a/Utilities/cmlibrhash/librhash/byte_order.h
+++ b/Utilities/cmlibrhash/librhash/byte_order.h
@@ -94,8 +94,14 @@ static inline uint32_t bswap_32(uint32_t x) {
(((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)
+# define bswap_64(x) __builtin_bswap64(x)
 #elif (_MSC_VER > 1300) && (defined(CPU_IA32) || defined(CPU_X64)) /* MS VC */
 # define bswap_64(x) _byteswap_uint64((__int64)x)
 #elif !defined(__STRICT_ANSI__)

---

Summary of changes:
 Utilities/cmlibrhash/librhash/byte_order.h |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)


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

[CMake] additional arguments with CMAKE_CXX_CLANG_TIDY variable

[Michael Ellery]

I asked this question on SO and am repeating here with the hope someone knows 
the answer:

http://stackoverflow.com/questions/40433573/how-can-i-specify-additional-arguments-for-use-with-cmake-cxx-clang-tidy-variabl

——
I'm trying to use make use of clang-tidy integration with cmake and I'd like to 
pass the -check argument. I've tried adding 
-DCMAKE_CXX_CLANG_TIDY="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*" 
when invoking cmake, but my makefile commands end-up looking like:

/usr/local/Cellar/cmake/3.6.2/bin/cmake -E __run_iwyu 
--tidy="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*" 
--source=/Users/ellery/work/.

in other words, it seems like the ; separated args are not being parsed apart. 
I've also tried setting the target property CXX_CLANG_TIDY directly on my 
target with the same value and I get the same behavior. If I remove ‘;checks=*’ 
from the string, everything works fine, but I get default clang-tidy behavior.

Has anyone succesfully invoked clang-tidy with additional args through cmake?
——

Thanks,
Mike Ellery



-- 

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

[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  3f7b09c95ee2efff892b5699fdc03a8ffc1423ac (commit)
   via  ff3b05d41b6a0b32697a8bd6096dacc8aed4 (commit)
   via  1d1f1eeb6a52d464d476eb0a46eb75c452e3dfbc (commit)
   via  479932fa32115b666be1deea42862673a0c4b608 (commit)
   via  925e4270fdc5c731c123cb8037607840008f4713 (commit)
  from  38ec4b15d232f45124fe290accc773284b99a679 (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=3f7b09c95ee2efff892b5699fdc03a8ffc1423ac
commit 3f7b09c95ee2efff892b5699fdc03a8ffc1423ac
Merge: 38ec4b1 ff3b05d
Author: Brad King 
AuthorDate: Tue Nov 8 10:48:39 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 10:48:39 2016 -0500

Merge topic 'imported-interface-libname' into next

ff3b05d4 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


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

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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

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


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

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

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.



  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.


A policy warning does not force your users to use a new CMake version.
In fact all that setting it to OLD does is suppress the warning.
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.


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] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio

[clinton]

- On Nov 8, 2016, at 8:13 AM, Taylor Braun-Jones tay...@braun-jones.org 
wrote:

> On Fri, Nov 4, 2016 at 2:55 PM, Brad King  wrote:
>>
>> On 11/03/2016 06:04 PM, John Drescher wrote:
>> > I opened a project in cmake-gui using the open project button from a
>> > vc 2010 build of a project. The open project opened the project in
>> > Visual Studio 2010. Later I opened the same project but a different
>> > build tree for Visual Studio 2013 CMake-gui had all of the correct
>> > information for the Visual Studio 2013 build but open project tried to
>> > open the Visual Studio 2013 solution in Visual Studio 2010 instead of
>> > the expected Visual Studio 2013.

I'm unable to reproduce this problem.  I have multiple Visual Studio 
installations of different versions.
I'm not sure whether it could be specific to a project, or specific to 
installations of visual studio.

> 
> I'm guessing you established MSVS2010 as the default application for
> opening .sln files the first time you used the open project button.
> What happens if you double click on that MSVS2013 .sln file?
> 
>> The feature is new in 3.7 and was contributed here:
>>
>>  cmake-gui: Add button to open the generated project
>>  https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1
>>
>> I'm not particularly familiar with how it works, but from a quick
>> glance at the code it may be using file associations.
> 
> Yes, it's just using Windows file file associations, but it shouldn't.
> Since it's possible (and fairly common) to have more than one version
> of Visual Studio installed on a system the Open Project button should
> be smarter and use ${CMAKE_VS_DEVENV_COMMAND} to open the .sln file.
> It should be something like this:
> 
> MSVS2015: %VS140COMNTOOLS%..\IDE\devenv.com
> MSVS2013: %VS120COMNTOOLS%..\IDE\devenv.com
> MSVS2012: %VS110COMNTOOLS%..\IDE\devenv.com
> MSVS2010: %VS100COMNTOOLS%..\IDE\devenv.com
> 
> If the correct devenv.exe path does not exist or can't be determined
> for some reason, then I guess it makes sense to fall back to using
> `QDesktopServices::openUrl` to try to open the .sln file with the
> Windows file associations.


It is already using QDesktopServices::openUrl(QUrl::fromLocalFile(...))
AFAIK, that is the correct way to do it.  The .sln file should already know 
what version of Visual Studio it wants to be opened in.

Clint
-- 

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 08-Nov-16 22:11, Dvir Yitzchaki wrote:
> But how do you know which version to declare on cmake_minimum_required?
I do hit this too. This would be a very useful feature. Sometimes I have
to manually "scan" the docs to figure out some simple facts about newly
introduces variables/commands.


On 08-Nov-16 22: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.
>>
>
> Strictly speaking cmake_minimum_required(VERSION) is not about command
> availability but rather about behavior (cmake policies).
Except it's exactly opposite :) `cmake_minimum_required` is about new
features/commands, and policies is about behavior. 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).

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] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio

[Taylor Braun-Jones]

On Fri, Nov 4, 2016 at 2:55 PM, Brad King  wrote:
>
> On 11/03/2016 06:04 PM, John Drescher wrote:
> > I opened a project in cmake-gui using the open project button from a
> > vc 2010 build of a project. The open project opened the project in
> > Visual Studio 2010. Later I opened the same project but a different
> > build tree for Visual Studio 2013 CMake-gui had all of the correct
> > information for the Visual Studio 2013 build but open project tried to
> > open the Visual Studio 2013 solution in Visual Studio 2010 instead of
> > the expected Visual Studio 2013.

I'm guessing you established MSVS2010 as the default application for
opening .sln files the first time you used the open project button.
What happens if you double click on that MSVS2013 .sln file?

> The feature is new in 3.7 and was contributed here:
>
>  cmake-gui: Add button to open the generated project
>  https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1
>
> I'm not particularly familiar with how it works, but from a quick
> glance at the code it may be using file associations.

Yes, it's just using Windows file file associations, but it shouldn't.
Since it's possible (and fairly common) to have more than one version
of Visual Studio installed on a system the Open Project button should
be smarter and use ${CMAKE_VS_DEVENV_COMMAND} to open the .sln file.
It should be something like this:

MSVS2015: %VS140COMNTOOLS%..\IDE\devenv.com
MSVS2013: %VS120COMNTOOLS%..\IDE\devenv.com
MSVS2012: %VS110COMNTOOLS%..\IDE\devenv.com
MSVS2010: %VS100COMNTOOLS%..\IDE\devenv.com

If the correct devenv.exe path does not exist or can't be determined
for some reason, then I guess it makes sense to fall back to using
`QDesktopServices::openUrl` to try to open the .sln file with the
Windows file associations.

Taylor
-- 

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

[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  38ec4b15d232f45124fe290accc773284b99a679 (commit)
   via  25cd3e21e86cefa0da6eac0ab54a3adc2d01fb72 (commit)
  from  edca8b6c81cee13aeb8bb2b14d4d3c4e79f11342 (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=38ec4b15d232f45124fe290accc773284b99a679
commit 38ec4b15d232f45124fe290accc773284b99a679
Merge: edca8b6 25cd3e2
Author: Brad King 
AuthorDate: Tue Nov 8 10:06:29 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 10:06:29 2016 -0500

Merge topic 'ExternalProject-GIT_CONFIG' into next

25cd3e21 ExternalProject: Allow passing config flags to git clone


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=25cd3e21e86cefa0da6eac0ab54a3adc2d01fb72
commit 25cd3e21e86cefa0da6eac0ab54a3adc2d01fb72
Author: Christian Fetzer 
AuthorDate: Mon Nov 7 21:53:23 2016 +0100
Commit: Brad King 
CommitDate: Tue Nov 8 09:57:32 2016 -0500

ExternalProject: Allow passing config flags to git clone

Add a `GIT_CONFIG` parameter that allows to specify `--config` flags
that are passed to the git clone command.  This can be used to specify
for example `core.autocrlf=true`.

diff --git a/Help/release/dev/ExternalProject-GIT_CONFIG.rst 
b/Help/release/dev/ExternalProject-GIT_CONFIG.rst
new file mode 100644
index 000..0702c55
--- /dev/null
+++ b/Help/release/dev/ExternalProject-GIT_CONFIG.rst
@@ -0,0 +1,5 @@
+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 1e0be09..84d5d1a 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -73,6 +73,10 @@ 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 ``
@@ -514,7 +518,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 
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 
git_config 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()
@@ -565,6 +569,11 @@ 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)
@@ -1812,6 +1821,7 @@ 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
@@ -1836,7 +1846,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}" ${src_name} ${work_dir}
+  ${GIT_EXECUTABLE} ${git_repository} ${git_tag} ${git_remote_name} 
"${git_submodules}" "${git_shallow}" "${git_progress}" "${git_config}" 
${src_name} ${work_dir}
   ${stamp_dir}/${name}-gitinfo.txt 
${stamp_dir}/${name}-gitclone-lastrun.txt "${tls_verify}"
   )
 set(comment "Performing download step (git 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-964-gedca8b6

[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  edca8b6c81cee13aeb8bb2b14d4d3c4e79f11342 (commit)
   via  f18b18b72b8f7f8dc21e350f4dd1c6931cdb389f (commit)
  from  b40c0bb7fa48d84edf00c1468b1ae17031d9e716 (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=edca8b6c81cee13aeb8bb2b14d4d3c4e79f11342
commit edca8b6c81cee13aeb8bb2b14d4d3c4e79f11342
Merge: b40c0bb f18b18b
Author: Brad King 
AuthorDate: Tue Nov 8 09:53:30 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 09:53:30 2016 -0500

Merge topic 'FindSDL_preventGrowingCacheVar' into next

f18b18b7 FindSDL: Prevent unbounded growth of SDL_LIBRARY_TEMP variable


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f18b18b72b8f7f8dc21e350f4dd1c6931cdb389f
commit f18b18b72b8f7f8dc21e350f4dd1c6931cdb389f
Author: Craig Scott 
AuthorDate: Sun Nov 6 17:37:54 2016 +1100
Commit: Brad King 
CommitDate: Tue Nov 8 09:52:55 2016 -0500

FindSDL: Prevent unbounded growth of SDL_LIBRARY_TEMP variable

Just modify the cache var property rather than using set() to hide it.
Otherwise the set() includes other values added to the temporary list.

Closes: #16406

diff --git a/Modules/FindSDL.cmake b/Modules/FindSDL.cmake
index 4e4411f..3410018 100644
--- a/Modules/FindSDL.cmake
+++ b/Modules/FindSDL.cmake
@@ -94,6 +94,11 @@ find_library(SDL_LIBRARY_TEMP
   PATH_SUFFIXES lib ${VC_LIB_PATH_SUFFIX}
 )
 
+# Hide this cache variable from the user, it's an internal implementation
+# detail. The documented library variable for the user is SDL_LIBRARY
+# which is derived from SDL_LIBRARY_TEMP further below.
+set_property(CACHE SDL_LIBRARY_TEMP PROPERTY TYPE INTERNAL)
+
 if(NOT SDL_BUILDING_LIBRARY)
   if(NOT SDL_INCLUDE_DIR MATCHES ".framework")
 # Non-OS X framework versions expect you to also dynamically link to
@@ -162,8 +167,6 @@ if(SDL_LIBRARY_TEMP)
 
   # Set the final string here so the GUI reflects the final state.
   set(SDL_LIBRARY ${SDL_LIBRARY_TEMP} CACHE STRING "Where the SDL Library can 
be found")
-  # Set the temp variable to INTERNAL so it is not seen in the CMake GUI
-  set(SDL_LIBRARY_TEMP "${SDL_LIBRARY_TEMP}" CACHE INTERNAL "")
 endif()
 
 if(SDL_INCLUDE_DIR AND EXISTS "${SDL_INCLUDE_DIR}/SDL_version.h")

---

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, next, updated. v3.7.0-rc3-950-g36bf6fd

[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  36bf6fd1d42550c4c42e23d4816b1b1031efcf03 (commit)
   via  c8a128147963eea8bf40125873c722370ab54b0c (commit)
  from  2a71480fa93b4c8bdb6485c1a78a9cd01f050791 (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=36bf6fd1d42550c4c42e23d4816b1b1031efcf03
commit 36bf6fd1d42550c4c42e23d4816b1b1031efcf03
Merge: 2a71480 c8a1281
Author: Brad King 
AuthorDate: Tue Nov 8 09:41:48 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 09:41:48 2016 -0500

Merge topic 'include-what-you-use' into next

c8a12814 fixup! Fix several include-what-you-use findings


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8a128147963eea8bf40125873c722370ab54b0c
commit c8a128147963eea8bf40125873c722370ab54b0c
Author: Brad King 
AuthorDate: Tue Nov 8 09:41:28 2016 -0500
Commit: Brad King 
CommitDate: Tue Nov 8 09:41:28 2016 -0500

fixup! Fix several include-what-you-use findings

diff --git a/Source/cmExecutionStatus.h b/Source/cmExecutionStatus.h
index 311c7f5..fd3c416 100644
--- a/Source/cmExecutionStatus.h
+++ b/Source/cmExecutionStatus.h
@@ -3,8 +3,6 @@
 #ifndef cmExecutionStatus_h
 #define cmExecutionStatus_h
 
-
-
 /** \class cmExecutionStatus
  * \brief Superclass for all command status classes
  *
diff --git a/Source/cmHexFileConverter.h b/Source/cmHexFileConverter.h
index 75c8028..1050bc1 100644
--- a/Source/cmHexFileConverter.h
+++ b/Source/cmHexFileConverter.h
@@ -3,8 +3,6 @@
 #ifndef cmHexFileConverter_h
 #define cmHexFileConverter_h
 
-
-
 /** \class cmHexFileConverter
  * \brief Can detects Intel Hex and Motorola S-record files and convert them
  *to binary files.
diff --git a/Source/cm_codecvt.hxx b/Source/cm_codecvt.hxx
index b9c1d62..fcd9954 100644
--- a/Source/cm_codecvt.hxx
+++ b/Source/cm_codecvt.hxx
@@ -5,9 +5,9 @@
 
 #include 
 
-#include 
 #include 
 #include 
+#include 
 
 class codecvt : public std::codecvt
 {

---

Summary of changes:
 Source/cmExecutionStatus.h  |2 --
 Source/cmHexFileConverter.h |2 --
 Source/cm_codecvt.hxx   |2 +-
 3 files changed, 1 insertion(+), 5 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-962-gb40c0bb

[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  b40c0bb7fa48d84edf00c1468b1ae17031d9e716 (commit)
   via  61898de64180ce8123219f5e6450cb8375840045 (commit)
  from  a5b31cdac6050fa034285a7aab63c1534c9b003e (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=b40c0bb7fa48d84edf00c1468b1ae17031d9e716
commit b40c0bb7fa48d84edf00c1468b1ae17031d9e716
Merge: a5b31cd 61898de
Author: Brad King 
AuthorDate: Tue Nov 8 09:48:19 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 09:48:19 2016 -0500

Merge topic 'pkgconfig_imported_target' into next

61898de6 PkgConfig: Fix FindPkgConfig imported target feature


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61898de64180ce8123219f5e6450cb8375840045
commit 61898de64180ce8123219f5e6450cb8375840045
Author: Florent Castelli 
AuthorDate: Fri Nov 4 23:35:27 2016 +0100
Commit: Florent Castelli 
CommitDate: Fri Nov 4 23:35:27 2016 +0100

PkgConfig: Fix FindPkgConfig imported target feature

The options to the find_library call to create the imported target
used a literal string "HINTS /path NO_DEFAULT_PATH" instead of a
list of options. This resulted in never finding any library in my
testing.

diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake
index 072a27a..3f75b19 100644
--- a/Modules/FindPkgConfig.cmake
+++ b/Modules/FindPkgConfig.cmake
@@ -193,7 +193,7 @@ function(_pkg_create_imp_target _prefix _no_cmake_path 
_no_cmake_environment_pat
   foreach (flag IN LISTS ${_prefix}_LDFLAGS)
 if (flag MATCHES "^-L(.*)")
   # only look into the given paths from now on
-  set(_find_opts "HINTS ${${CMAKE_MATCH_1}} NO_DEFAULT_PATH")
+  set(_find_opts HINTS ${CMAKE_MATCH_1} NO_DEFAULT_PATH)
   continue()
 endif()
 if (flag MATCHES "^-l(.*)")

---

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc3-960-ga5b31cd

[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  a5b31cdac6050fa034285a7aab63c1534c9b003e (commit)
   via  666bb0e3fa0d212c03f785bd9f6bc05d29925e1f (commit)
   via  4ec359bd6256e870d9b233fd5cd105e452a62300 (commit)
   via  049b10e2f621800f0b8da1918784dad7a049d6a8 (commit)
   via  69bb9f37f9b71a109ef9547af25144e207f116e4 (commit)
   via  48910cf0968a4c5b4ffd9093972498920404685f (commit)
   via  9df1cb0fa68869f8125025f20fa8c64467aab2e8 (commit)
   via  d568cecf38a6a4b399c925fd3553dd4a273d0af1 (commit)
  from  ddb04ebae16819485e7c4150250bb17c47fd0358 (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=a5b31cdac6050fa034285a7aab63c1534c9b003e
commit a5b31cdac6050fa034285a7aab63c1534c9b003e
Merge: ddb04eb 666bb0e
Author: Brad King 
AuthorDate: Tue Nov 8 09:44:56 2016 -0500
Commit: Brad King 
CommitDate: Tue Nov 8 09:44:56 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-444-g666bb0e

[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  666bb0e3fa0d212c03f785bd9f6bc05d29925e1f (commit)
   via  2e620f0b3834e5a612a38d61b7e50a561d7f11e8 (commit)
  from  4ec359bd6256e870d9b233fd5cd105e452a62300 (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=666bb0e3fa0d212c03f785bd9f6bc05d29925e1f
commit 666bb0e3fa0d212c03f785bd9f6bc05d29925e1f
Merge: 4ec359b 2e620f0
Author: Brad King 
AuthorDate: Tue Nov 8 09:44:40 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 09:44:40 2016 -0500

Merge topic 'include-what-you-use'

2e620f0b Fix several include-what-you-use findings


---

Summary of changes:
 Source/CTest/cmCTestScriptHandler.cxx  |1 +
 Source/QtDialog/CMakeSetup.cxx |2 ++
 Source/cmAlgorithms.h  |   14 ++--
 Source/cmCMakeMinimumRequired.cxx  |6 
 Source/cmCMakeMinimumRequired.h|6 
 Source/cmCTest.cxx |   45 
 Source/cmCacheManager.cxx  |   11 +++---
 Source/cmCacheManager.h|6 ++--
 Source/cmCommandArgumentsHelper.h  |6 ++--
 Source/cmCommonTargetGenerator.cxx |3 +-
 Source/cmCommonTargetGenerator.h   |5 +--
 Source/cmConditionEvaluator.cxx|   12 ++-
 Source/cmConditionEvaluator.h  |   10 --
 Source/cmCoreTryCompile.cxx|   14 ++--
 Source/cmCoreTryCompile.h  |5 +++
 Source/cmCreateTestSourceList.cxx  |4 +++
 Source/cmCreateTestSourceList.h|7 
 Source/cmDefinitions.cxx   |1 +
 Source/cmDefinitions.h |8 ++---
 Source/cmDependsC.cxx  |7 ++--
 Source/cmDependsFortran.cxx|   17 -
 Source/cmDependsJavaParserHelper.h |2 ++
 Source/cmExecutionStatus.h |4 ---
 Source/cmExpandedCommandArgument.h |4 +--
 Source/cmExportBuildAndroidMKGenerator.cxx |   18 +++---
 Source/cmExportBuildAndroidMKGenerator.h   |   10 --
 Source/cmExportInstallAndroidMKGenerator.cxx   |   11 +++---
 Source/cmExportInstallAndroidMKGenerator.h |   10 +-
 Source/cmExtraCodeBlocksGenerator.cxx  |   11 +++---
 Source/cmExtraEclipseCDT4Generator.cxx |   17 +
 Source/cmExtraSublimeTextGenerator.cxx |   14 
 Source/cmFileCommand.cxx   |1 +
 Source/cmFileTimeComparison.cxx|1 -
 Source/cmFindBase.cxx  |6 
 Source/cmFindBase.h|5 +++
 Source/cmFindCommon.cxx|7 ++--
 Source/cmFindCommon.h  |9 +
 Source/cmFunctionBlocker.h |7 ++--
 Source/cmFunctionCommand.cxx   |1 -
 Source/cmGeneratedFileStream.cxx   |5 +--
 Source/cmGeneratorExpression.cxx   |7 ++--
 Source/cmGeneratorExpressionEvaluationFile.cxx |   11 +++---
 Source/cmGeneratorExpressionEvaluationFile.h   |   13 ---
 Source/cmGeneratorTarget.cxx   |   22 ++--
 Source/cmGetCMakePropertyCommand.cxx   |1 -
 Source/cmGlobalBorlandMakefileGenerator.cxx|1 +
 Source/cmGlobalGenerator.cxx   |   21 +--
 Source/cmGlobalGenerator.h |   22 ++--
 Source/cmGlobalGeneratorFactory.h  |7 ++--
 Source/cmGlobalJOMMakefileGenerator.cxx|1 +
 Source/cmGlobalMSYSMakefileGenerator.cxx   |4 ++-
 Source/cmGlobalMinGWMakefileGenerator.cxx  |1 +
 Source/cmGlobalNMakeMakefileGenerator.cxx  |1 +
 Source/cmGlobalNinjaGenerator.cxx  |   24 -
 Source/cmGlobalNinjaGenerator.h|   22 +++-
 Source/cmGlobalUnixMakefileGenerator3.cxx  |   11 +++---
 Source/cmGlobalUnixMakefileGenerator3.h|   10 +++---
 Source/cmGlobalWatcomWMakeGenerator.cxx|1 -
 Source/cmGraphAdjacencyList.h  |4 +--
 Source/cmGraphVizWriter.cxx|   11 +++---
 Source/cmHexFileConverter.cxx  |5 +--
 Source/cmHexFileConverter.h|4 ---
 Source/cmInstallCommand.cxx|

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc3-442-g4ec359b

[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  4ec359bd6256e870d9b233fd5cd105e452a62300 (commit)
   via  0cd654c8e23b19311bae876ada4ad5b432c1ad1b (commit)
   via  bac93dcf192d8680cd72570682d6593da9818088 (commit)
   via  1e994985d83b09d71b4928a61a75d1cf3861aaec (commit)
   via  5ae3966d75593b05a9658af8d2fdd47c2bf48a4d (commit)
   via  443180fb9915eefe0b232875505632ffb9fabb95 (commit)
  from  049b10e2f621800f0b8da1918784dad7a049d6a8 (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=4ec359bd6256e870d9b233fd5cd105e452a62300
commit 4ec359bd6256e870d9b233fd5cd105e452a62300
Merge: 049b10e 0cd654c
Author: Brad King 
AuthorDate: Tue Nov 8 09:44:37 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 09:44:37 2016 -0500

Merge topic 'clang-tidy'

0cd654c8 cmGeneratorTarget: Correctly set FortranModuleDirectoryCreated
bac93dcf cmGeneratorTarget: Don't assing a bool to a string
1e994985 cmGlobalNinjaGenerator: Suppress clang-tidy warning
5ae3966d cmCTestSubmitHandler: Remove redundant c_str()
443180fb cmCPluginAPI: Fix clang-tidy findings


---

Summary of changes:
 Source/CTest/cmCTestSubmitHandler.cxx |2 +-
 Source/cmCPluginAPI.cxx   |8 
 Source/cmGeneratorTarget.cxx  |2 +-
 Source/cmGlobalNinjaGenerator.cxx |4 ++--
 4 files changed, 8 insertions(+), 8 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-431-g69bb9f3

[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  69bb9f37f9b71a109ef9547af25144e207f116e4 (commit)
   via  80e477239dc3a57f87f9efb7b1d78eb0f0e2b6a3 (commit)
  from  48910cf0968a4c5b4ffd9093972498920404685f (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=69bb9f37f9b71a109ef9547af25144e207f116e4
commit 69bb9f37f9b71a109ef9547af25144e207f116e4
Merge: 48910cf 80e4772
Author: Brad King 
AuthorDate: Tue Nov 8 09:44:31 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 09:44:31 2016 -0500

Merge topic 'FortranCInterface-pic'

80e47723 FortranCInterface: Make mangling detection robust to PIC Fortran


---

Summary of changes:
 Modules/FortranCInterface/CMakeLists.txt |3 +++
 1 file changed, 3 insertions(+)


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

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc3-436-g049b10e

[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  049b10e2f621800f0b8da1918784dad7a049d6a8 (commit)
   via  b34c045736384fc3ba8574b33211bd75082bc07b (commit)
   via  cd0423300bea21a5c0747a6aeaefbae24c10ecd8 (commit)
   via  228280d8334f2bcac346e5f0d3ea802af7f22862 (commit)
   via  d8e83ab979b0ccfc4887dbf48c088a72dffb2e96 (commit)
  from  69bb9f37f9b71a109ef9547af25144e207f116e4 (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=049b10e2f621800f0b8da1918784dad7a049d6a8
commit 049b10e2f621800f0b8da1918784dad7a049d6a8
Merge: 69bb9f3 b34c045
Author: Brad King 
AuthorDate: Tue Nov 8 09:44:34 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 09:44:34 2016 -0500

Merge topic 'cpack-rpm-omit-unsupported-tags'

b34c0457 Release text for omitting unsupported tags topic
cd042330 CPack/RPM test for Suggests tag
228280d8 CPack/RPM prevent special tags from being removed
d8e83ab9 CPack/RPM omit unsupported tags


---

Summary of changes:
 .../dev/cpack-rpm-omit-unsupported-tags.rst|8 +
 Modules/CPackRPM.cmake |   24 +++
 ...iles.cmake => RPM_SUGGESTS-ExpectedFiles.cmake} |2 +-
 .../CPack/RPM/RPM_SUGGESTS-VerifyResult.cmake  |   31 
 Tests/RunCMake/CPack/RPM_SUGGESTS.cmake|4 +++
 Tests/RunCMake/CPack/RunCMakeTest.cmake|1 +
 6 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 Help/release/dev/cpack-rpm-omit-unsupported-tags.rst
 copy Tests/RunCMake/CPack/RPM/{MINIMAL-ExpectedFiles.cmake => 
RPM_SUGGESTS-ExpectedFiles.cmake} (77%)
 create mode 100644 Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-VerifyResult.cmake
 create mode 100644 Tests/RunCMake/CPack/RPM_SUGGESTS.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, next, updated. v3.7.0-rc3-952-gddb04eb

[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  ddb04ebae16819485e7c4150250bb17c47fd0358 (commit)
   via  2e620f0b3834e5a612a38d61b7e50a561d7f11e8 (commit)
  from  36bf6fd1d42550c4c42e23d4816b1b1031efcf03 (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=ddb04ebae16819485e7c4150250bb17c47fd0358
commit ddb04ebae16819485e7c4150250bb17c47fd0358
Merge: 36bf6fd 2e620f0
Author: Brad King 
AuthorDate: Tue Nov 8 09:43:26 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Nov 8 09:43:26 2016 -0500

Merge topic 'include-what-you-use' into next

2e620f0b Fix several include-what-you-use findings


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2e620f0b3834e5a612a38d61b7e50a561d7f11e8
commit 2e620f0b3834e5a612a38d61b7e50a561d7f11e8
Author: Daniel Pfeifer 
AuthorDate: Sat Nov 5 21:40:14 2016 +0100
Commit: Brad King 
CommitDate: Tue Nov 8 09:42:04 2016 -0500

Fix several include-what-you-use findings

diff --git a/Source/CTest/cmCTestScriptHandler.cxx 
b/Source/CTest/cmCTestScriptHandler.cxx
index 7ee0f75..08ea4ee 100644
--- a/Source/CTest/cmCTestScriptHandler.cxx
+++ b/Source/CTest/cmCTestScriptHandler.cxx
@@ -22,6 +22,7 @@
 #include "cmGlobalGenerator.h"
 #include "cmMakefile.h"
 #include "cmState.h"
+#include "cmStateDirectory.h"
 #include "cmStateTypes.h"
 #include "cmSystemTools.h"
 #include "cmake.h"
diff --git a/Source/QtDialog/CMakeSetup.cxx b/Source/QtDialog/CMakeSetup.cxx
index 9038469..5e03c39 100644
--- a/Source/QtDialog/CMakeSetup.cxx
+++ b/Source/QtDialog/CMakeSetup.cxx
@@ -5,6 +5,7 @@
 #include "CMakeSetupDialog.h"
 #include "cmAlgorithms.h"
 #include "cmDocumentation.h"
+#include "cmDocumentationEntry.h"
 #include "cmVersion.h"
 #include "cmake.h"
 #include 
@@ -17,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cmSystemTools.h" // IWYU pragma: keep
 
diff --git a/Source/cmAlgorithms.h b/Source/cmAlgorithms.h
index aa55379..22f69fa 100644
--- a/Source/cmAlgorithms.h
+++ b/Source/cmAlgorithms.h
@@ -3,9 +3,17 @@
 #ifndef cmAlgorithms_h
 #define cmAlgorithms_h
 
-#include 
-
-#include "cmStandardIncludes.h"
+#include  // IWYU pragma: keep
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 inline bool cmHasLiteralPrefixImpl(const std::string& str1, const char* str2,
size_t N)
diff --git a/Source/cmCMakeMinimumRequired.cxx 
b/Source/cmCMakeMinimumRequired.cxx
index 655c42a..942688c 100644
--- a/Source/cmCMakeMinimumRequired.cxx
+++ b/Source/cmCMakeMinimumRequired.cxx
@@ -2,9 +2,15 @@
file Copyright.txt or https://cmake.org/licensing for details.  */
 #include "cmCMakeMinimumRequired.h"
 
+#include 
+#include 
+
 #include "cmMakefile.h"
 #include "cmSystemTools.h"
 #include "cmVersion.h"
+#include "cmake.h"
+
+class cmExecutionStatus;
 
 // cmCMakeMinimumRequired
 bool cmCMakeMinimumRequired::InitialPass(std::vector const& args,
diff --git a/Source/cmCMakeMinimumRequired.h b/Source/cmCMakeMinimumRequired.h
index 3acedd2..08a5c38 100644
--- a/Source/cmCMakeMinimumRequired.h
+++ b/Source/cmCMakeMinimumRequired.h
@@ -3,8 +3,14 @@
 #ifndef cmCMakeMinimumRequired_h
 #define cmCMakeMinimumRequired_h
 
+#include 
+#include 
+#include 
+
 #include "cmCommand.h"
 
+class cmExecutionStatus;
+
 /** \class cmCMakeMinimumRequired
  * \brief cmake_minimum_required command
  *
diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index 024260c..010fc4e 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx
@@ -2,6 +2,27 @@
file Copyright.txt or https://cmake.org/licensing for details.  */
 #include "cmCTest.h"
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include "cmAlgorithms.h"
 #include "cmCTestBuildAndTestHandler.h"
 #include "cmCTestBuildHandler.h"
@@ -21,35 +42,15 @@
 #include "cmGlobalGenerator.h"
 #include "cmMakefile.h"
 #include "cmState.h"
+#include "cmStateSnapshot.h"
 #include "cmStateTypes.h"
 #include "cmSystemTools.h"
 #include "cmVersion.h"
 #include "cmVersionConfig.h"
 #include "cmXMLWriter.h"
+#include "cm_auto_ptr.hxx"
 #include "cmake.h"
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
 #if 

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

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.



Strictly speaking cmake_minimum_required(VERSION) is not about command 
availability but rather about behavior (cmake policies).
CMake does not diagnose or prevent use of commands that were introduced 
after the current policy version.


No automation can detect which behaviors you might expect or require 
based on the commands you are using.


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.
For existing projects policy warnings help migrating to newer behaviors 
and versions as they become available / justifiable.


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

[Dvir Yitzchaki]

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.

Regards,

Dvir

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Nils Gladitz
Sent: Tuesday, November 08, 2016 3:37 PM
To: Louis-Paul CORDIER ; Cmake Mailing List 

Subject: Re: [CMake] Adding Cmake version in online documentation

On 11/08/2016 10:57 AM, Louis-Paul CORDIER wrote:

> Hi,
>
> This is a feature proposal for the documentation. Cmake is making use 
> of cmake_minimum_required() command, that is very useful.
> Unfortunately it is very hard to identify commands that will work 
> without browsing all version of cmake documentation for a given command.
>

This has been brought up for discussion more than once e.g.:
 https://public.kitware.com/Bug/view.php?id=15517
 https://public.kitware.com/Bug/view.php?id=15222
 http://public.kitware.com/pipermail/cmake/2016-April/063306.html

Personally I still don't think this needs change.
You don't have to browse all versions of the documentation ... you only 
have to work with the documentation that matches the version you 
declared in cmake_minimum_required().

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

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 11/08/2016 10:57 AM, Louis-Paul CORDIER wrote:


Hi,

This is a feature proposal for the documentation. Cmake is making use 
of cmake_minimum_required() command, that is very useful. 
Unfortunately it is very hard to identify commands that will work 
without browsing all version of cmake documentation for a given command.




This has been brought up for discussion more than once e.g.:
https://public.kitware.com/Bug/view.php?id=15517
https://public.kitware.com/Bug/view.php?id=15222
http://public.kitware.com/pipermail/cmake/2016-April/063306.html

Personally I still don't think this needs change.
You don't have to browse all versions of the documentation ... you only 
have to work with the documentation that matches the version you 
declared in cmake_minimum_required().


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

[Michael Jackson]

+1
--
Mike Jackson  [mike.jack...@bluequartz.net]


Louis-Paul CORDIER wrote:

Hi,

This is a feature proposal for the documentation. Cmake is making use of
cmake_minimum_required() command, that is very useful. Unfortunately it
is very hard to identify commands that will work without browsing all
version of cmake documentation for a given command.

That said, adding a "since version" number for a feature/command would
be great, like cplusplus.com does (example here:
http://www.cplusplus.com/reference/unordered_map/unordered_map/?kw=unordered_map)

For instance, the command

list(FILTER ...)

has been introduced in Cmake 3.6. Why not adding

list(FILTER ...) (since 3.6)

?
--

*Best Regards/
Louis-Paul CORDIER
*


--

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

[Louis-Paul CORDIER]

Hi,

This is a feature proposal for the documentation. Cmake is making use of 
cmake_minimum_required() command, that is very useful. Unfortunately it 
is very hard to identify commands that will work without browsing all 
version of cmake documentation for a given command.


That said, adding a "since version" number for a feature/command would 
be great, like cplusplus.com does (example here: 
http://www.cplusplus.com/reference/unordered_map/unordered_map/?kw=unordered_map)


For instance, the command

list(FILTER ...)

has been introduced in Cmake 3.6. Why not adding

list(FILTER ...) (since 3.6)

?
--

*Best Regards/
Louis-Paul CORDIER
*

-- 

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