[CMake] Determine Verbosity in Custom Language Scripts

[David Zemon]

I've defined a custom language for my project which is simply a wrapper
around GCC. The "compiler" for this language is a CMake script which
invokes g++ followed by objcopy. I would like to use CMake's standard
verbosity system - either VERBOSE=1 for Unix Makefiles or -v or Ninja
(maybe there are others too?) but I don't know how. I was previously doing
something like

```
if (ENV{VERBOSE})
  message("g++ ${SOURCE}")
endif ()
execute_process(COMMAND g++ ${SOURCE})
```

but Ninja doesn't set an environment variable. Is it possible do this?

Thank you,
David Zemon
-- 

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] Why does INTERFACE type targets only support whitelisted properties?

[Taylor Braun-Jones]

On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz  wrote:

>
>
> On 01/08/2016 02:50 PM, Yves Frederix wrote:
>
>> You are explicitly mentioning 'setting' of a property. IMHO there is a
>> big difference between setting and getting a property. If
>> white/blacklisting is enforced during setting only, wouldn't this be
>> sufficient? This would make it possible to simply access all
>> properties that are automatically assigned to the target (which I
>> assume implies that by definition they should make sense?). A
>> non-acceptable property could not have been set and would hence not be
>> found, making it possible to check for its existence in the "standard"
>> way.
>>
>
> The same argument might hold for getting of properties.
> E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties
> now but was implemented in the future.
>
> A user might e.g. think that a specific property should work because CMake
>>> did not issue any diagnostics and open an issue.
>>> The diagnostic implies that this behavior is by design.
>>>
>>> It also prevents users from using existing properties which currently
>>> don't
>>> have semantics for INTERFACE targets but might be implemented in the
>>> future
>>> (potentially with different semantics than expected by the user).
>>>
>> Ok, this somehow contradicts my above assumption and is somewhat
>> surprising. Wouldn't it make sense to simply not set these properties
>> in the first place if they have incorrect semantics? This way,
>> get_property would not need to care about them and it would anyhow not
>> stop their correct implementation in the future.
>>
>
> I meant existing as in defined for regular build targets not as in
> actually set for interface targets.
> get_property() would return an empty string for those if they weren't
> whitelisted and one might argue that this could suffice.
> On the other hand users often assume that they get a valid value and don't
> actually check.
>
>
>>> I think allowing custom (non cmake defined) properties might be a valid
>>> argument.
>>> These could perhaps also be supported through e.g. user extension of the
>>> whitelist.
>>>
>> I like this idea. With this in place, one would not need to wait for a
>> new CMake release if a valid property were missing from the whitelist
>> or if one wanted to use custom properties.
>>
>> I don't think anything should be changed however unless there are actual
>>> use
>>> cases that aren't supported by the current implementation.
>>>
>> Does this mean that you would have doubts about patches that:
>>   - provide a way for the user to extend the whitelist?
>>   - remove the need for whitelisting in get_property by making CMake
>> only automatically assign sensible target properties?
>>
>
> The issue is less that CMake assigns these properties (I don't know of any
> such case but I haven't checked) and more that users might just expect them
> to be set (which does not provide a diagnostic).
>
> Personally I would not object to either approach as long as there are
> actual use cases.
> Without use cases such changes would be by definition useless.


I have another INTERFACE property use case that is not whitelisted, but
should be: VERSION

Consider library project Foo that uses a header-only project Bar. In
FooConfig.cmake, it is a important to ensure any projects using Foo also
use the exact same version of Bar that Foo was originally built with
(Failure to do so can lead to subtle, hard-to-find bugs like violation of
the one definition rule). Assuming project Bar creates an imported target
"Bar" with a VERSION property set like:

  set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3)

Then project Foo should be able to have something like:

== CMakeLists.txt ==
...
get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION)
configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY)

== FooConfig.cmake.in ==
...
find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED)

But, alas, this is not currently possible. I'm ambivalent about whether
INTERFACE properties should be whitelisted vs blacklisted vs unrestricted,
but at least this VERSION property seems valid to allow.

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

Re: [CMake] Why does INTERFACE type targets only support whitelisted properties?

[Stephen Kelly]

Taylor Braun-Jones wrote:

> Consider library project Foo that uses a header-only project Bar. In
> FooConfig.cmake, it is a important to ensure any projects using Foo also
> use the exact same version of Bar that Foo was originally built with

COMPATIBLE_INTERFACE_STRING and similar properties are designed for that use 
case. 

You would populate an INTERFACE_ property on the INTERFACE target, which is 
whitelisted already:

 
https://cmake.org/cmake/help/v3.4/manual/cmake-buildsystem.7.html#compatible-interface-properties

 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/5813

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Why does INTERFACE type targets only support whitelisted properties?

[Taylor Braun-Jones]

On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz  wrote:

>
>
> On 01/08/2016 02:50 PM, Yves Frederix wrote:
>
>> You are explicitly mentioning 'setting' of a property. IMHO there is a
>> big difference between setting and getting a property. If
>> white/blacklisting is enforced during setting only, wouldn't this be
>> sufficient? This would make it possible to simply access all
>> properties that are automatically assigned to the target (which I
>> assume implies that by definition they should make sense?). A
>> non-acceptable property could not have been set and would hence not be
>> found, making it possible to check for its existence in the "standard"
>> way.
>>
>
> The same argument might hold for getting of properties.
> E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties
> now but was implemented in the future.
>
> A user might e.g. think that a specific property should work because CMake
>>> did not issue any diagnostics and open an issue.
>>> The diagnostic implies that this behavior is by design.
>>>
>>> It also prevents users from using existing properties which currently
>>> don't
>>> have semantics for INTERFACE targets but might be implemented in the
>>> future
>>> (potentially with different semantics than expected by the user).
>>>
>> Ok, this somehow contradicts my above assumption and is somewhat
>> surprising. Wouldn't it make sense to simply not set these properties
>> in the first place if they have incorrect semantics? This way,
>> get_property would not need to care about them and it would anyhow not
>> stop their correct implementation in the future.
>>
>
> I meant existing as in defined for regular build targets not as in
> actually set for interface targets.
> get_property() would return an empty string for those if they weren't
> whitelisted and one might argue that this could suffice.
> On the other hand users often assume that they get a valid value and don't
> actually check.
>
>
>>> I think allowing custom (non cmake defined) properties might be a valid
>>> argument.
>>> These could perhaps also be supported through e.g. user extension of the
>>> whitelist.
>>>
>> I like this idea. With this in place, one would not need to wait for a
>> new CMake release if a valid property were missing from the whitelist
>> or if one wanted to use custom properties.
>>
>> I don't think anything should be changed however unless there are actual
>>> use
>>> cases that aren't supported by the current implementation.
>>>
>> Does this mean that you would have doubts about patches that:
>>   - provide a way for the user to extend the whitelist?
>>   - remove the need for whitelisting in get_property by making CMake
>> only automatically assign sensible target properties?
>>
>
> The issue is less that CMake assigns these properties (I don't know of any
> such case but I haven't checked) and more that users might just expect them
> to be set (which does not provide a diagnostic).
>
> Personally I would not object to either approach as long as there are
> actual use cases.
> Without use cases such changes would be by definition useless.


I have another INTERFACE property use case that is not whitelisted, but
should be: VERSION

Consider library project Foo that uses a header-only project Bar. In
FooConfig.cmake, it is a important to ensure any projects using Foo also
use the exact same version of Bar that Foo was originally built with
(Failure to do so can lead to subtle, hard-to-find bugs like violation of
the one definition rule). Assuming project Bar creates an imported target
"Bar" with a VERSION property set like:

  set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3)

Then project Foo should be able to have something like:

== CMakeLists.txt ==
...
get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION)
configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY)

== FooConfig.cmake.in ==
...
find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED)

But, alas, this is not currently possible. I'm ambivalent about whether
INTERFACE properties should be whitelisted vs blacklisted vs unrestricted,
but at least this VERSION property seems valid to allow.

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

Re: [cmake-developers] CMake daemon for user tools

[Alexander Neundorf]

On Monday, January 11, 2016 15:59:35 Aleix Pol wrote:
...
> 
> Hi Stephen, everyone,
> I've already discussed this in private with you. I think it's a good
> idea and I'd like to make sure we can benefit from this.
> 
> I'm unsure of the feasibility of the project though. 

you maybe remember that my main issue with your patch last year was that it's 
not a "generator", while it does what generators are for.
After talking with Milian a bit several week ago, I understood that an 
important reason why the kdevelop team does not want a generator is that there 
is only one generator per build-tree, i.e. the user has to decide beforehand 
which IDE project files he wants.
With the branch I created on github a few days ago, which I announced here 
too, I changed the way the extra generators are activated: they are not 
activated like the main generators anymore, but can be turned on and off using 
normal cmake cache options, so multiple generators (e.g. the generic json 
generator and let's say the Eclipse generator) can both be turned on, 
initially or later on. I think this should solve this problem.
The work there 
(https://github.com/neundorf/CMake/tree/RefactorExtraGeneratorsExperimental ) 
is not ready for inclusing, but it shows how it can be done and can serve as a 
starting point/inspiration.

Stephens big approach will need some time until it is ready, while such a 
(relatively) simple thing can probably be done within one release cycle (but I 
don't have the time to do it).

I don't know what the others here think about adding your json-approach or 
not.

Alex

-- 

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 alternative language (was: Using CMake as a library from Python)

[Petr Kmoch]

Hi all.

I'd like to voice my opinion as a somewhat advanced CMake user here.

For me, one of the strongest points of CMake is the fact that its project
specification is procedural rather than declarative. In my current job, for
example, we have a significant framework built in CMake which handles a lot
of unique setups we have (which were largely inherited from a previous
inhouse buildsystem). Yes, the end result of our framework is that the
CMakeLists consist mostly of declarative commands from our framework, but
the implementation of these commands is heavily procedural. I am convinced
that if CMake didn't give us the procedural power required to make this
work, we couldn't have adopted it. (I had previously tried emulating bits
of this setup in a more declarative system and failed miserably).

Of course (having written much of this framework I'm talking about above),
I know all too well that a better front-end language would do a world of
good for CMake. I also understand that taking a more declarative approach
could help that, and I'm not opposed to such a change in principle.
However, please take care not to throw the baby out with the bathwater and
nerf the expressiveness of what can be done with CMake (in a procedural
way).

If I understand Brad's suggestion correctly, it would amount to a (possibly
empty) procedural step being used to generate a declarative description of
the buildsystem. This would work well in our scenario, I believe, as long
as that procedural step could be sufficiently modularised on the client
side.

I fully support introducing an alternative input language to CMake and
taking all steps necessary for this to happen, but please do this in a way
which will not restrict what CMake is capable of doing.

Petr

On Fri, Jan 8, 2016 at 5:30 PM, Brad King  wrote:

> Hi Charles,
>
> Thanks for your efforts in exploring this topic.  CMake's current language
> grew incrementally out of something that was not originally intended as a
> programming language.  The cmState refactoring Stephen Kelly has started
> is a huge step toward enabling alternative languages, but there is a long
> way to go.
>
> A few general thoughts:
>
> * One rule we have for CMake is to never expose any public SDK of the C++
>   implementation structures.  We want to be able to rewrite them
> arbitrarily
>   at any time.  Therefore any solution that needs to access the C++
>   structures must be integrated into CMake upstream and expose
> functionality
>   only through other languages or file formats.
>
> * The cmState infrastructure builds on a "snapshot" design with a goal of
>   being able to "fork" configuration/generation temporarily and then revert
>   back, and to be able to re-start configuration from the middle.  These
>   goals may be incompatible with any language whose implementation we do
>   not fully control unless it is allowed to execute only in isolated and
>   independent snippets.  These are not hard goals, but it is a trade-off
>   to keep in mind.  Stephen may be able to elaborate more on the snapshot
>   approach if needed.
>
> * A problem with the current design is that the entire configuration
> process
>   is logically serial making parallel evaluation hard or impossible.  In
>   many cases each add_subdirectory can be processed independently, but this
>   will require semantic changes to allow.
>
> On 01/04/2016 02:41 AM, Charles Huet wrote:
> > I'm trying to be as declarative as possible, because really like how
> readable
> > simple QML programs are, and I think it would be perfect for a
> buildsystem.
>
> Ideally most of the specification (sources, libraries, executables, etc.)
> should be in a pure format that can be evaluated without side effects (e.g.
> declarative or functional).  This rules out both Python and Lua, but the
> specification format does not have to be the main entry point.  There could
> be some imperative configuration step that does system introspection and
> then loads the pure specification and evaluates it as needed for the
> specific
> environment.
>
> If we're going to go through the effort to provide an alternative input
> format,
> I think we should strive for this approach because it will be more
> flexible in
> the long run.  A pure specification format will allow easy loading/saving
> by
> other tools, IDEs, etc., without having to process any imperative logic.
>
> > Actually, I'm directly using the cmMakefile, because I did not want to
> wrap all
> > the commands, and it seemed backwards to me to wrap them.
>
> Yes.  Any alternative format should be processed directly into the
> structures
> used by the generators.  The cmState work has separated the generate-time
> representation quite a bit from the configuration-time
> (cmake-language-specific)
> representation, but I think there is still further work needed to finish
> that.
>
> >> Having said all that, Brad favors Lua I believe, and he favors a
> different
> >> approach 

[Cmake-commits] CMake branch, master, updated. v3.4.1-801-gcd9a59b

[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  cd9a59b1993bc7732dae4d683c5864847f36a046 (commit)
  from  cedbb7994dddce2c3fdf846bf4563c846adf4632 (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=cd9a59b1993bc7732dae4d683c5864847f36a046
commit cd9a59b1993bc7732dae4d683c5864847f36a046
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Jan 12 00:01:09 2016 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Jan 12 00:01:09 2016 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index d44f58e..585f6e0 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 4)
-set(CMake_VERSION_PATCH 20160111)
+set(CMake_VERSION_PATCH 20160112)
 #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] CMake incorrectly passes linker flags to ar

[Alan Burlison]

On 11/01/2016 17:48, Brad King wrote:


That is not representative of CMake in general.  If there is a better
way for FindJNI to get the information it needs then it would be great
to have needed changes contributed.


The Hadoop CMake infrastructure contains pretty much a complete rewrite 
of the JNI detection code for Linux, on other platforms it seems to be 
possible to get away with just tweaking things slightly before calling 
the standard CMake JNI module. The problem of course is all the 
cross-platform testing any wholesale rewrite would entail...



The Hadoop CMakeLists.txt files don't use a PROJECT() command. The CMake
docs say if you don't do so then an implicit PROJECT() is added that
selects the C & C++ languages, is that done before processing any other
commands in CMakeLists.txt?


Yes, the implicit project() call is inserted on line zero of the top-level
CMakeLists.txt file.  This feature is meant to help people get started
with hello-world projects and is not meant for use by mature projects.
The top-level CMakeLists.txt file of a "real" project should start with

  cmake_minimum_required(VERSION ...)
  project(MyProject)

Flags affecting the target architecture are typically expected to be
provided by the user calling CMake, not by project code, and so will
be set before languages are enabled by this project() command.


That's not the way CMake is used for building Hadoop, CMake is called by 
Ant and/or Maven, users don't call CMake directly. I suspect that's not 
too uncommon, when CMake is used to build just the native components of 
a larger platform-independent system.


--
Alan Burlison
--
--

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.4.1-1907-g77b3007

[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  77b30076c63f1e8f3155148a0c9815745b58d24c (commit)
   via  4d05f195d9518eb5075f5b2a024f6c5874aab042 (commit)
  from  8673afc72a2ba9ba8d7184411b4b1247ea45d774 (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=77b30076c63f1e8f3155148a0c9815745b58d24c
commit 77b30076c63f1e8f3155148a0c9815745b58d24c
Merge: 8673afc 4d05f19
Author: Brad King 
AuthorDate: Mon Jan 11 16:35:08 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 11 16:35:08 2016 -0500

Merge topic 'FindwxWidgets-use-isystem' into next

4d05f195 FindwxWidgets: Drop suppression of -isystem


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d05f195d9518eb5075f5b2a024f6c5874aab042
commit 4d05f195d9518eb5075f5b2a024f6c5874aab042
Author: Brad King 
AuthorDate: Mon Jan 11 16:21:13 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 11 16:26:24 2016 -0500

FindwxWidgets: Drop suppression of -isystem

This was added by commit v2.8.0~2292 (... Set variable
wxWidgets_INCLUDE_DIRS_NO_SYSTEM on the Mac ..., 2008-04-16) and updated
by commit v2.8.9~183^2 (FindwxWidgets: Do not use -isystem on OpenBSD,
2012-05-14).  Since the underlying cause was never investigated fully we
do not know the conditions under which -isystem breaks wxWidgets, but
suppressing -isystem is problematic for users that do not want to see
warnings in wxWidgets headers.  Simply drop the special case for now so
we can see whether anyone hits the problem again, at which point it can
be investigated in more detail.

Reported-by: Simon Wells 

diff --git a/Modules/FindwxWidgets.cmake b/Modules/FindwxWidgets.cmake
index 9037594..49ce57e 100644
--- a/Modules/FindwxWidgets.cmake
+++ b/Modules/FindwxWidgets.cmake
@@ -188,18 +188,6 @@ set(wxWidgets_LIBRARIES"")
 set(wxWidgets_LIBRARY_DIRS "")
 set(wxWidgets_CXX_FLAGS"")
 
-# Using SYSTEM with INCLUDE_DIRECTORIES in conjunction with wxWidgets on
-# the Mac produces compiler errors. Set wxWidgets_INCLUDE_DIRS_NO_SYSTEM
-# to prevent UsewxWidgets.cmake from using SYSTEM.
-#
-# See cmake mailing list discussions for more info:
-#   https://cmake.org/pipermail/cmake/2008-April/021115.html
-#   https://cmake.org/pipermail/cmake/2008-April/021146.html
-#
-if(APPLE OR CMAKE_CXX_PLATFORM_ID MATCHES "OpenBSD")
-  set(wxWidgets_INCLUDE_DIRS_NO_SYSTEM 1)
-endif()
-
 # DEPRECATED: This is a patch to support the DEPRECATED use of
 # wxWidgets_USE_LIBS.
 #

---

Summary of changes:
 Modules/FindwxWidgets.cmake |   12 
 1 file changed, 12 deletions(-)


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

Re: [cmake-developers] FindwxWidgets.cmake

[Brad King]

On 01/11/2016 01:18 PM, Simon Wells wrote:
> The following code is line 191-201, I have tested without this being set
> on OSX 10.11 using system clang and both self-built and brew installed
> wxwidgets with no problems, Whether its still an issue using gcc on osx
> or some other configuration i am unsure, but is it worth being more
> specific than just If APPLE for this bug-fix/workaround

Thanks.  The only way to get more detail on the problems is to wait for
someone to hit them again.  Meanwhile we can just restore -isystem:

 FindwxWidgets: Drop suppression of -isystem
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d05f195

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

[Brad King]

Hi Folks,

I'm replying directly to my previous post in this thread in order to consolidate
responses to related discussion raised in others' responses to it:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389

General comments:

* There is a lot of code out there in the current CMake language so I do not
  think it is realistic to drop it.  I'm not proposing that this change.

* CMake's procedural/imperative design is good as the main entry point to
  configuration of a project.  It can do system introspection, file generation,
  etc.  I'm not proposing that this change.

* Many projects build elaborate macro/function systems in the CMake language
  in order to end up with a declarative specification listing the actual
  source files, dependencies, and usage requirements.  I'd like to offer
  an alternative to this.

* Integration with IDEs is currently based on one-way generation (VS IDE
  projects, Xcode projects, CodeBlocks, etc.).  Editing the project build
  specification requires editing CMake code directly because IDEs cannot
  easily pierce CMake's procedural/imperative specification:

https://cmake.org/pipermail/cmake-developers/2016-January/027386.html

  I'd like to improve this by *optionally* moving part of the specification
  to a (stateless) declarative format that IDEs can load/edit/save directly.

Specific responses follow.



On 01/11/2016 12:24 PM, Charles Huet wrote:
> I think these goals aim towards a faster configure, and the ability to
> only partly reconfigure, right?

Yes.

> I know I am largely biased by the project I work on, but I do not see how
> parallel evaluation woud be a huge benefit.
[snip]
> And how would that work with CMakeLists that affect their parent scope ?

Evaluation of the imperative language is currently serial for reasons like
this, which is why I said it would take semantic changes to enable parallel
evaluation. This is not the main point of my proposal so I'd rather not
get bogged down in the details of this part of the discussion.

>> Ideally most of the specification (sources, libraries, executables, etc.)
>> should be in a pure format that can be evaluated without side effects (e.g.
>> declarative or functional).
>
> I'm not sure I understand how this could be done without losing a lot of
> what CMake offers, such as copying or generating files.

I'm not proposing dropping the current imperative capabilities.

> I'm leaning towards a declarative approach as it is quite easy to learn
> (since you declare objects, and every C++ programmer I know is familiar
> with those)

Yes.

> It seems you are leaning towards pure functional, but I do not see how
> this would work with the current way CMake handles variables and scope,
> could you elaborate ?

While declarative may get us most of the way, advanced users may wish to
hook in to generation-time evaluation. A clean way to do that would be
to specify a function within the declared values. It would not have to
be in a functional language as long as it has no access to anything other
than the inputs passed to it during evaluation.

I mentioned "functional" mostly as an example of a specification whose
evaluation is free of side effects.

> To clarify, only the following lines should be considered when looking at the 
> POC.
>> myProject=cmake.Project("MyTestProject")
>> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])]

Yes, this is the kind of stuff that can be in a declarative format.

> It seems you have in mind to write a new CMake language.

No, at most a new specification format that can be used for IDE integration.
If some kind of user-coded function were included in the specification it
should certainly be in an existing language.

> Maybe I should take my POC further

I think implementation even of a POC is premature at this point.  We
should explore the design space further.

> CMake's own buildsystem seems like a good testing ground for this, but
> it is a little too big for a first go, do you know of a small CMake-based
> project that would be better suited ?

Maybe you could find something in our test suite.

> I don't have a clear view of what a pure functional CMake would look like,
> but if you give me some mock code, I could give a try at bringing some pure
> functional language up to the level of my POC and we could use it as a more
> concrete discussion support.

I have no prototype (nor substantial time to spend on design myself) but
I've imagined a declarative format in a well-known syntax (e.g. JSON or one
of the lightweight human-friendly choices).  If generate-time functionality
is needed then code snippets in e.g. Lua could be included.

[cmake-developers] [CMake 0015909]: FindDCMTK.cmake outdated

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15909 
== 
Reported By:dkuegler
Assigned To:
== 
Project:CMake
Issue ID:   15909
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-11 16:07 EST
Last Modified:  2016-01-11 16:07 EST
== 
Summary:FindDCMTK.cmake outdated
Description: 
The FindDCMTK in CMake is very outdated. It produces errors and all the
libraries and paths have to be set up manually.

The script straight up, does not find DCMTK, even if specifically pointed to the
right path with DCMTK_DIR.

But there is a up-to-date buildscript, that works properly in the CTK toolkit:
https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake

So I would propose to use that file.

Steps to Reproduce: 
install DCMTK
build DCMTK

create a CMakeLists.txt with
set(DCMTK path/to/dcmtk/build/folder)
find_package(DCMTK)

Additional Information: 
tested with Windows 8.1, CMake 3.3, 3.4
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-11 16:07 dkuegler   New Issue
==

-- 

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-developers] Visual Studio 2015 FastLink

[Thomas]

Dear Cmake developers,
as a follow up of this bug
https://cmake.org/Bug/view.php?id=15894

I'm writing to request support for the /Debug:FastLink flag which was
introduced in visual studio 2015 (update 1), and the option to generate
full PDB informations.
http://blogs.msdn.com/b/vcblog/archive/2015/10/16/debug-fastlink-for-vs2015-update-1.aspx

Brad King already setup the correct framework in "next" branch to implement
the /Debug:FastLink and with the proposed patch (last topic in the bug) it
works good.

About the "Generate Full PDB informations" , is a new option that can be
used to re-use pdbs generated with the fastlink flag in a different
computer from the one who did the compilation (it may be useful sometimes).
That option seems to doesn't have a (public) command line switch, instead
it relies on an XML property.

When the user requests "Generate Full PDB informations", the generator
should add
true
in the  section.

What's the best way to set a TARGET or global property which would enable
the switchless XML property in the generator?

Thanks!
Qb
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake based package manager

[Ruslan Baratov via CMake]

On 11-Jan-16 18:42, Cristian Adam wrote:

Ruslan Baratov via CMake  writes:


Hi,

I'm developing a project that is a kind of wrapper of
ExternalProject_Add and
allow it to be more reusable. User interface is quite simple.

For anybody interested, here is a github project:

* https://github.com/ruslo/hunter

Recently posted on reddit:
https://www.reddit.com/r/cpp/comments/40cfbk/hunter_crossplatform_packag
e_manager_for_c/

Any thoughts of including such a project in CMake?
Just for your information there is no need to include all this project, 
the entry point to everything is HunterGate.cmake module (500 lines of 
CMake code): 
https://github.com/hunter-packages/gate/blob/master/cmake/HunterGate.cmake


I will be happy to add it to CMake's standard modules so users can avoid 
one copy/paste step, if CMake's team is interested.


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

[Cmake-commits] CMake branch, master, updated. v3.4.1-800-gcedbb79

[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  cedbb7994dddce2c3fdf846bf4563c846adf4632 (commit)
   via  f086c665da00228cabf465dc1eb7223d40fd6270 (commit)
  from  d9f9c4fbc0a02f048793f4b91aeb5c65d9571e84 (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=cedbb7994dddce2c3fdf846bf4563c846adf4632
commit cedbb7994dddce2c3fdf846bf4563c846adf4632
Merge: d9f9c4f f086c66
Author: Brad King 
AuthorDate: Mon Jan 11 09:17:41 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 11 09:17:41 2016 -0500

Merge topic 'vs14-debug-enum'

f086c665 VS: Fix VS 2015 .vcxproj file value for GenerateDebugInformation 
(#15894)

diff --cc Source/cmVisualStudio10TargetGenerator.cxx
index 6e1fb5b,6b46773..669c785
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@@ -2603,13 -2591,20 +2611,21 @@@ cmVisualStudio10TargetGenerator::Comput
}
  else
{
-   linkOptions.AddFlag("GenerateDebugInformation", "false");
+   if (this->LocalGenerator->GetVersion() >=
+   cmGlobalVisualStudioGenerator::VS14)
+ {
+ linkOptions.AddFlag("GenerateDebugInformation", "No");
+ }
+   else
+ {
+ linkOptions.AddFlag("GenerateDebugInformation", "false");
+ }
}
 -std::string pdb = this->Target->GetPDBDirectory(config.c_str());
 +std::string pdb = this->GeneratorTarget->GetPDBDirectory(config.c_str());
  pdb += "/";
  pdb += targetNamePDB;
 -std::string imLib = this->Target->GetDirectory(config.c_str(), true);
 +std::string imLib =
 +this->GeneratorTarget->GetDirectory(config.c_str(), true);
  imLib += "/";
  imLib += targetNameImport;
  

---

Summary of changes:
 Source/cmVisualStudio10TargetGenerator.cxx |   20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)


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

[Cmake-commits] CMake branch, master, updated. v3.4.1-798-gd9f9c4f

[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  d9f9c4fbc0a02f048793f4b91aeb5c65d9571e84 (commit)
   via  2b48f63ce38e49a5c3ee84aa3763da00c8af08f3 (commit)
  from  196d912200667750d73d872c1c237eebe9d426e0 (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=d9f9c4fbc0a02f048793f4b91aeb5c65d9571e84
commit d9f9c4fbc0a02f048793f4b91aeb5c65d9571e84
Merge: 196d912 2b48f63
Author: Brad King 
AuthorDate: Mon Jan 11 09:17:38 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 11 09:17:38 2016 -0500

Merge topic 'FindBLAS-intel-64lp'

2b48f63c FindBLAS: Fix pattern matching on BLAS vendor name


---

Summary of changes:
 Modules/FindBLAS.cmake |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)


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

Re: [CMake] CMake based package manager

[Nicholas Braden]

Doesn't biicode already fill this role? Biicode seems to work well
enough for me, anyway.

On Mon, Jan 11, 2016 at 5:42 AM, Cristian Adam  wrote:
> Ruslan Baratov via CMake  writes:
>
>>
>> Hi,
>>
>> I'm developing a project that is a kind of wrapper of
>> ExternalProject_Add and
>> allow it to be more reusable. User interface is quite simple.
>>
>> For anybody interested, here is a github project:
>>
>> * https://github.com/ruslo/hunter
>
> Recently posted on reddit:
> https://www.reddit.com/r/cpp/comments/40cfbk/hunter_crossplatform_packag
> e_manager_for_c/
>
> Any thoughts of including such a project in CMake?
>
> Cheers,
> Cristian.
>
>
> --
>
> 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] CMake based package manager

[Cristian Adam]

On Mon, Jan 11, 2016 at 2:33 PM, Nicholas Braden  wrote:

> Doesn't biicode already fill this role? Biicode seems to work well
> enough for me, anyway.
>
>
Biicode is dead.

There is a comparison with biicode here:
https://github.com/ruslo/hunter/issues/54

Having only CMake as a dependency is awesome!

I have tried once to reuse biicode's OpenSSL CMake files, I failed. So I
ended up
using perl and whatever OpenSSL needed to compile.

On the other hand hunter has only CMake as dependency, which means that its
CMake scripts are very portable.

Cheers,
Cristian.
-- 

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.4.1-1891-g816fe03

[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  816fe03a024f0d2b315c9797e48a4e58a7ae0490 (commit)
   via  cedbb7994dddce2c3fdf846bf4563c846adf4632 (commit)
   via  d9f9c4fbc0a02f048793f4b91aeb5c65d9571e84 (commit)
   via  196d912200667750d73d872c1c237eebe9d426e0 (commit)
   via  7a45d91dc4dcbf52a576cca37878bc5c37f293f3 (commit)
   via  c6ff95be6113bb2880653caa4efc0d125016f7e0 (commit)
  from  558d5d986886e224346cee5b992920ec073cb6d7 (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=816fe03a024f0d2b315c9797e48a4e58a7ae0490
commit 816fe03a024f0d2b315c9797e48a4e58a7ae0490
Merge: 558d5d9 cedbb79
Author: Brad King 
AuthorDate: Mon Jan 11 09:17:56 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 11 09:17: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

Re: [CMake] CMake based package manager

[Cristian Adam]

Ruslan Baratov via CMake  writes:

> 
> Hi,
> 
> I'm developing a project that is a kind of wrapper of 
> ExternalProject_Add and
> allow it to be more reusable. User interface is quite simple.
> 
> For anybody interested, here is a github project:
> 
> * https://github.com/ruslo/hunter

Recently posted on reddit: 
https://www.reddit.com/r/cpp/comments/40cfbk/hunter_crossplatform_packag
e_manager_for_c/

Any thoughts of including such a project in CMake? 

Cheers,
Cristian.


-- 

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.4.1-1895-gebf86b8

[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  ebf86b8bf65ec96e48f814d3f454106201df3538 (commit)
   via  b3677b35d320cce5d23831ec398d6bb283d1444e (commit)
   via  c22da7cff74a293d6362598c2a381147d658022f (commit)
   via  4ca9df8bd1991870a8a4acfeae26933e8ca7dc9a (commit)
  from  816fe03a024f0d2b315c9797e48a4e58a7ae0490 (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=ebf86b8bf65ec96e48f814d3f454106201df3538
commit ebf86b8bf65ec96e48f814d3f454106201df3538
Merge: 816fe03 b3677b3
Author: Brad King 
AuthorDate: Mon Jan 11 09:52:06 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 11 09:52:06 2016 -0500

Merge topic 'vs-link-debug-property' into next

b3677b35 VS: Map the link `/debug` to its IDE property
c22da7cf VS: Drop unused condition in link debug flag generation
4ca9df8b cmIDEOptions: Add support for case-insensitive flags


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3677b35d320cce5d23831ec398d6bb283d1444e
commit b3677b35d320cce5d23831ec398d6bb283d1444e
Author: Brad King 
AuthorDate: Fri Jan 8 14:38:58 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 11 09:45:00 2016 -0500

VS: Map the link `/debug` to its IDE property

Fix the link flag table entries for this flag to be case-insensitive.
Also fix the VS 2015 value for the build property enumeration name.

This causes `linkOptions.Parse(...)` to correctly extract the `/debug`
flag and map it to the IDE property instead.  Therefore we do not need
to look for the flag explicitly when initializing the property.

diff --git a/Source/cmVS10LinkFlagTable.h b/Source/cmVS10LinkFlagTable.h
index f6b758d..dd92329 100644
--- a/Source/cmVS10LinkFlagTable.h
+++ b/Source/cmVS10LinkFlagTable.h
@@ -155,7 +155,8 @@ static cmVS7FlagTable cmVS10LinkFlagTable[] =
   {"AllowIsolation", "ALLOWISOLATION:NO", "", "false", 0},
   {"UACUIAccess", "uiAccess='false'", "", "false", 0},
   {"UACUIAccess", "uiAccess='true'", "", "true", 0},
-  {"GenerateDebugInformation", "DEBUG", "", "true", 0},
+  {"GenerateDebugInformation", "DEBUG", "", "true",
+   cmVS7FlagTable::CaseInsensitive},
   {"MapExports", "MAPINFO:EXPORTS", "", "true", 0},
   {"AssemblyDebug", "ASSEMBLYDEBUG:DISABLE", "", "false", 0},
   {"AssemblyDebug", "ASSEMBLYDEBUG", "", "true", 0},
diff --git a/Source/cmVS11LinkFlagTable.h b/Source/cmVS11LinkFlagTable.h
index 0f641e4..2d6f6c0 100644
--- a/Source/cmVS11LinkFlagTable.h
+++ b/Source/cmVS11LinkFlagTable.h
@@ -177,7 +177,8 @@ static cmVS7FlagTable cmVS11LinkFlagTable[] =
   {"UACUIAccess", "uiAccess='false'", "", "false", 0},
   {"UACUIAccess", "uiAccess='true'", "", "true", 0},
   {"ManifestEmbed", "manifest:embed", "", "true", 0},
-  {"GenerateDebugInformation", "DEBUG", "", "true", 0},
+  {"GenerateDebugInformation", "DEBUG", "", "true",
+   cmVS7FlagTable::CaseInsensitive},
   {"MapExports", "MAPINFO:EXPORTS", "", "true", 0},
   {"AssemblyDebug", "ASSEMBLYDEBUG:DISABLE", "", "false", 0},
   {"AssemblyDebug", "ASSEMBLYDEBUG", "", "true", 0},
diff --git a/Source/cmVS12LinkFlagTable.h b/Source/cmVS12LinkFlagTable.h
index e5a570e..0be5e34 100644
--- a/Source/cmVS12LinkFlagTable.h
+++ b/Source/cmVS12LinkFlagTable.h
@@ -177,7 +177,8 @@ static cmVS7FlagTable cmVS12LinkFlagTable[] =
   {"UACUIAccess", "uiAccess='false'", "", "false", 0},
   {"UACUIAccess", "uiAccess='true'", "", "true", 0},
   {"ManifestEmbed", "manifest:embed", "", "true", 0},
-  {"GenerateDebugInformation", "DEBUG", "", "true", 0},
+  {"GenerateDebugInformation", "DEBUG", "", "true",
+   cmVS7FlagTable::CaseInsensitive},
   {"MapExports", "MAPINFO:EXPORTS", "", "true", 0},
   {"AssemblyDebug", "ASSEMBLYDEBUG:DISABLE", "", "false", 0},
   {"AssemblyDebug", "ASSEMBLYDEBUG", "", "true", 0},
diff --git a/Source/cmVS14LinkFlagTable.h b/Source/cmVS14LinkFlagTable.h
index 6d81d12..1e781e8 100644
--- a/Source/cmVS14LinkFlagTable.h
+++ b/Source/cmVS14LinkFlagTable.h
@@ -177,7 +177,8 @@ static cmVS7FlagTable cmVS14LinkFlagTable[] =
   {"UACUIAccess", "uiAccess='false'", "", "false", 0},
   {"UACUIAccess", "uiAccess='true'", "", "true", 0},
   {"ManifestEmbed", "manifest:embed", "", "true", 0},
-  {"GenerateDebugInformation", "DEBUG", "", "true", 0},
+  {"GenerateDebugInformation", "DEBUG", "", "Debug",
+   cmVS7FlagTable::CaseInsensitive},
   {"MapExports", "MAPINFO:EXPORTS", "", "true", 0},
   {"AssemblyDebug", "ASSEMBLYDEBUG:DISABLE", "", "false", 0},
   {"AssemblyDebug", "ASSEMBLYDEBUG", "", "true", 0},
diff --git 

Re: [CMake] CMake incorrectly passes linker flags to ar

[Brad King]

On 01/11/2016 10:49 AM, Alan Burlison wrote:
> So is the answer here to add -m64 just to CMAKE_EXE_LINKER_FLAGS and 
> CMAKE_SHARED_LINKER_FLAGS and not to CMAKE_STATIC_LINKER_FLAGS? Are 
> CMAKE_STATIC_LINKER_FLAGS only ever used with ar?

Yes and yes.  Actually adding -m64 to CMAKE_{C,CXX}_FLAGS may be
enough because IIRC CMake uses those when invoking the C or C++
compiler front-end for linking a shared library or executable.

> There seems to be an assumption baked into CMake that if the underlying 
> OS is *nix and is 32-bit then all executables that run on it are 32 bit 
> and if it is 64-bit then all the executables are 64-bit as well, so 
> looking at 'uname -p' is sufficient to determine the type of executables 
> that should be produced. Unfortunately that's not correct for either 
> Solaris or Linux.

Very few decisions are actually made based on CMAKE_SYSTEM_PROCESSOR.
Most platform tuning is done based on the compiler id detection results
which uses the actual toolchain.  For example, CMAKE_SIZEOF_VOID_P is
set to the data pointer size detected from the toolchain target.

If you're not adding -m64 to the CMAKE_{C,CXX}_FLAGS until after the
top-level project() command enables the C and CXX languages then it is
too late for those flags to affect the detected target architecture.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

[Charles Huet]

Hi,

> * The cmState infrastructure builds on a "snapshot" design with a goal of
  being able to "fork" configuration/generation temporarily and then revert
  back, and to be able to re-start configuration from the middle.  These
  goals may be incompatible with any language whose implementation we do
  not fully control unless it is allowed to execute only in isolated and
  independent snippets.  These are not hard goals, but it is a trade-off
  to keep in mind.  Stephen may be able to elaborate more on the snapshot
  approach if needed.

I think these goals aim towards a faster configure, and the ability to only
partly reconfigure, right ?

> * A problem with the current design is that the entire configuration
process
  is logically serial making parallel evaluation hard or impossible.  In
  many cases each add_subdirectory can be processed independently, but this
  will require semantic changes to allow.

I know I am largely biased by the project I work on, but I do not see how
parallel evaluation woud be a huge benefit. We basically have a "core"
library, and lots of libs that link against it (and other libs, such as
third parties).
How would a target B that depends on lib A be processed in this case ?
Wouldn't the evaluation of the link_libraries of B be waiting for the
evaluation of A to finish ?
If this is the case, then parallel evaluation would be only a slight
benefit (again, heavily biased by the project I work on).
And how would that work with CMakeLists that affect their parent scope ?

> Ideally most of the specification (sources, libraries, executables, etc.)
should be in a pure format that can be evaluated without side effects (e.g.
declarative or functional).

I'm not sure I understand how this could be done without losing a lot of
what CMake offers, such as copying or generating files.
I'm leaning towards a declarative approach as it is quite easy to learn
(since you declare objects, and every C++ programmer I know is familiar
with those), and functional, while powerfull and very elegant for some
things, is quite foreign to C+ programmers as a whole (I know C++11 adds
this, but it will be years until this can be used in production for lots of
C++ users, because of old compilers that are still supported for business
reasons).
Moreover, object-oriented is easy to introspect, offering an abstract
representation for IDEs and tools.

It seems you are leaning towards pure functional, but I do not see how this
would work with the current way CMake handles variables and scope, could
you elaborate ?


> I do not think we should have the build specification depend on processing
code like this.  It is not compatible with cmake-gui where the configuration
and generation steps are triggered by the user.

My POC is far from complete, and what I had in mind to keep the CMake-gui
approach was to make generating optional in CLI through a parameter. Thus
executing the script would only configure, which would populate the
CMakeCache, allowing the user to modify variables and such, then configure.
To clarify, only the following lines should be considered when looking at
the POC.
> myProject=cmake.Project("MyTestProject")
> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])]


> In summary, I think work in this direction should first focus on designing
a declarative (or functional) specification format where most of the project
information can be specified.  Then a cmake-language command can be written
to load and evaluate a specification file (as a transition).  Finally we
could look at replacing the entry-point language with something else.  At
that point we could have closures passed as parameters to the evaluation of
the pure spec in order to get custom generate-time logic.

It seems you have in mind to write a new CMake language. I'd rather see an
existing language used, such as OCaml or lisp if you want a pure functional
language. Those are supported by SWIG so prototyping would be easy.
Javascript is even an option that is not *completely* crazy, as it has a
C-Style syntax  so it would be an easy language to write in for C++
programmers.

I think using an existing language has quite a few benefits:
* no need to design or implement a language
* lots of existing resources on how to do things
* lots of existing libraries (data structures, file system operations, etc)
* tooling (auto-complete, debugging, profiling, linting, etc)

Maybe I should take my POC further, in order to see the failings of this
approach, and maybe the same should be done for a more functional approach.
CMake's own buildsystem seems like a good testing ground for this, but it
is a little too big for a first go, do you know of a small CMake-based
project that would be better suited ?

I don't have a clear view of what a pure functional CMake would look like,
but if you give me some mock code, I could give a try at bringing some pure
functional language up to the level of my POC and we could use it as a more

Re: [CMake] CMake incorrectly passes linker flags to ar

[Alan Burlison]

On 11/01/2016 16:13, Brad King wrote:


On 01/11/2016 10:49 AM, Alan Burlison wrote:

So is the answer here to add -m64 just to CMAKE_EXE_LINKER_FLAGS and
CMAKE_SHARED_LINKER_FLAGS and not to CMAKE_STATIC_LINKER_FLAGS? Are
CMAKE_STATIC_LINKER_FLAGS only ever used with ar?


Yes and yes.  Actually adding -m64 to CMAKE_{C,CXX}_FLAGS may be
enough because IIRC CMake uses those when invoking the C or C++
compiler front-end for linking a shared library or executable.


Thanks, I've removed -m64 from CMAKE_STATIC_LINKER_FLAGS and with 3.3.2 
on Solaris it fixes the problem, I'll ring the changes on the other 
platforms and with 2.8.6 and make sure it still works elsewhere.



There seems to be an assumption baked into CMake that if the underlying
OS is *nix and is 32-bit then all executables that run on it are 32 bit
and if it is 64-bit then all the executables are 64-bit as well, so
looking at 'uname -p' is sufficient to determine the type of executables
that should be produced. Unfortunately that's not correct for either
Solaris or Linux.


Very few decisions are actually made based on CMAKE_SYSTEM_PROCESSOR.
Most platform tuning is done based on the compiler id detection results
which uses the actual toolchain.  For example, CMAKE_SIZEOF_VOID_P is
set to the data pointer size detected from the toolchain target.


ISTR part of the issue at least was in the bowels of the CMake FindJNI 
module, that makes extensive use of CMAKE_SYSTEM_PROCESSOR.



If you're not adding -m64 to the CMAKE_{C,CXX}_FLAGS until after the
top-level project() command enables the C and CXX languages then it is
too late for those flags to affect the detected target architecture.


The Hadoop CMakeLists.txt files don't use a PROJECT() command. The CMake 
docs say if you don't do so then an implicit PROJECT() is added that 
selects the C & C++ languages, is that done before processing any other 
commands in CMakeLists.txt? If so then from what you say it seems 
setting CMAKE_{C,CXX}_FLAGS wouldn't have any effect, which is probably 
why it has been done via CMAKE_EXE_LINKER_FLAGS etc.


--
Alan Burlison
--
--

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 daemon for user tools

[Aleix Pol]

On Sun, Jan 10, 2016 at 12:10 PM, Stephen Kelly  wrote:
>
> Hello,
>
> I've been working on adding a daemon mode for cmake to provide
> information to user tools - such as IDEs - about the buildsystem.
>
> Following the discussion about providing metadata for IDEs to consume
> I proposed creating a long-running process which would provide a protocol
> to access information about the buildsystem, and about the content of the
> cmake files themselves:
>
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004
>
> The original post in that thread lists design goals.
>
> This design is independent of any generator, and compared to the solution of
> writing json to a file, this solution doesn't require generating
> anything that is
> not asked for.  This also side-steps the problem of 'stale' files remaining
> in the build directory, and the problem of needing to trigger re-generation
> of the file, or watching it for changes.  This solution also allows
> parameters (eg the config) to be specified in requests, side-stepping a
> difficulty we encountered before to represent things like that.  This
> solution also does not require actually generating the buildsystem
> files. Only the configure and compute steps of cmake are executed.
>
> I am scheduled to give a talk at FOSDEM about the feature and how user
> tools can interact with it:
>
>  https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code
>
> with a preview in Berlin:
>
>  http://www.meetup.com/berlincplusplus/events/227896427/
>
> I have now also pushed a branch to my github clone with the start of the
> server mode:
>
>  https://github.com/steveire/CMake/commits/cmake-daemon
>
> Currently the branch only makes targets and backtraces etc available via
> the protocol.  I have also created a plan for extending the protocol to
> make code completion and variable debugging possible, and analysed the
> depedencies of the tasks:
>
>  http://www.steveire.com/cmake-daemon-tasks.png
>
> However, I can't complete those tasks myself: I don't have
> relevant experience building IDEs to know how best to design the
> protocol, what IDE tools really need, how to design a fail-safe parser
> etc.  Additionally, I think a design which incorporates design ideas
> and implementation from more than one person will be better in the end.
>
> So, this needs to be a collaborative effort if it is to go anywhere, with
> more people writing commits in the cmake repo.
>
> The above (copied below) task list would be enough to get a read-only
> browser of a cmake project quite quickly.
>
> Following that, an effort would be needed to handle the difference
> between the dirty state of an editor and the on-disk file content. That's
> a solvable problem and together with filesystem notifications provided
> by libuv, it will lead to features like code completion.
>
> Also necessary eventually would be to make the cmake parser more
> fail-safe, so that information is still available if the user
> had not yet closed a command argument list for example, and make the
> processing more fail-safe in the case where they have written
> add_subdirectory(foo), but have not yet created foo/CMakeLists.txt.
>
> I would be looking to people who work on IDEs for guidance on how to do
> things like that, as some of them are likely already for handling C++
> code in the IDEs.
>
> So, this needs to be a collaborative effort. I can provide guidance to
> anyone who wishes to participate in changing the source code of CMake
> to make it possible.
>
> Is anyone interested enough in this potential cmake feature to
> join the development effort?
>
> Thanks,
>
> Steve.
>
>
> * Provide basic daemon mode with event loop and communication protocol
> -- Written, but not reviewed
> * Provide protocol to query the buildsystem structure
> -- Written, but not complete or reviewed
> * Extend cmListFileParser to record location of start and end of commands
> * Rewrite cmIfCommand to record which branches are executed
> * Store the location of start and end of user-defined functions
> * Provide protocol to query for unexecuted lines
> * Define a new snapshot type to occur at an arbitrary point
> * Create snapshots after branching to other files (after an include() or
> find_package() or add_subdirectory etc)
> * Create snapshots after points with external effects (file(WRITE),
> configure_file(), execute_process etc)
> * Find most recent snapshot occuring before a specified line
> * Implement feature to start at a specific snapshot and execute commands
> up to a particular line
> * Make server find correct snapshot to start at and execute required
> commands up to specified line
> * Provide protocol to dump variable defintions at a particular line
> * Extract implementation of IssueMessage from cmMakefile and
> cmLocalGenerator into cmake
> * Extract computed target properties from cmTarget::GetProperty into
> cmComputedTargetProperties
> * Implement 

Re: [CMake] CMake incorrectly passes linker flags to ar

[Alan Burlison]

On 11/01/2016 15:26, Brad King wrote:


What is adding -m64 to CMAKE_STATIC_LINKER_FLAGS?  That value is indeed
meant to be used to pass flags to "ar" because CMake (for historical
reasons) abuses the term "linker" to refer to the archiver used for a
static library.


That's been added by in a CMakeLists.txt via an include of a common 
cmake script for setting up the per-platform compilation flags.


https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/HadoopCommon.cmake

elseif(CMAKE_SYSTEM_NAME STREQUAL "SunOS")
# Solaris flags. 64-bit compilation is mandatory, and is checked 
earlier.
hadoop_add_compiler_flags("-m64 -D__EXTENSIONS__ 
-D_POSIX_PTHREAD_SEMANTICS -D_XOPEN_SOURCE=500")

hadoop_add_linker_flags("-m64")

which calls:

# Add flags to all the CMake compiler variables
macro(hadoop_add_compiler_flags FLAGS)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${FLAGS}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${FLAGS}")
endmacro()

# Add flags to all the CMake linker variables
macro(hadoop_add_linker_flags FLAGS)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${FLAGS}")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${FLAGS}")
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} ${FLAGS}")
endmacro()

So is the answer here to add -m64 just to CMAKE_EXE_LINKER_FLAGS and 
CMAKE_SHARED_LINKER_FLAGS and not to CMAKE_STATIC_LINKER_FLAGS? Are 
CMAKE_STATIC_LINKER_FLAGS only ever used with ar?



But I'm struggling to understand when passing in linker flags to ar
*ever* makes sense, at least on *nix platforms.


The name "LINK_FLAGS" is used as a placeholder there to share the
implementation with similar substitutions done in actual link line
generation.  See above about the naming.

The question here is what changed between 2.8.6 and 3.3.2 that causes
-m64 to start showing up in CMAKE_STATIC_LINKER_FLAGS.


Yes indeed, if I'd been able to figure that out I think I'd have been 
able to figure out how to change the CMake macros to get round the problem.


It's not the only problem I have hit with CMake's Solaris support, see 
for example 
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/HadoopCommon.cmake#L194


# CMAKE_SYSTEM_PROCESSOR is set to the output of 'uname -p', which on 
Solaris is
# the 'lowest' ISA supported, i.e. 'i386' or 'sparc'. However in order 
for the
# standard CMake modules to look in the right places it needs to reflect 
the required
# compilation mode, i.e. 64 bit. We therefore force it to either 'amd64' 
or 'sparcv9'.


There seems to be an assumption baked into CMake that if the underlying 
OS is *nix and is 32-bit then all executables that run on it are 32 bit 
and if it is 64-bit then all the executables are 64-bit as well, so 
looking at 'uname -p' is sufficient to determine the type of executables 
that should be produced. Unfortunately that's not correct for either 
Solaris or Linux.


Thanks,

--
Alan Burlison
--
--

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] CMake incorrectly passes linker flags to ar

[Alan Burlison]

I've just moved from CMake 2.8.6 to 3.3.2 and creation of static 
libraries is now failing. I've localised the problem as far as the 
generated link.txt linker script. With 2.8 it begins with:


/usr/bin/ar cr target/usr/local/lib/libhadoop.a

with 3.3.2 it begins with:

/usr/bin/ar cq target/usr/local/lib/libhadoop.a -m64

The "-m64" flag is used to tell the compiler/linker to create 64-bit 
executables and is set via the following CMake variables:


CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS

However "-m64" is not a valid "ar" flag. I haven't been able to find 
exactly how the linker flags are transmogrified into ar flags but I did 
find the following in Modules/CMakeCXXInformation.cmake:


if(NOT DEFINED CMAKE_CXX_ARCHIVE_CREATE)
  set(CMAKE_CXX_ARCHIVE_CREATE " cq   
")

endif()

But I'm struggling to understand when passing in linker flags to ar 
*ever* makes sense, at least on *nix platforms. And that code seems to 
be the same in 2.8.6 and 3.3.2 so it doesn't explain why the incorrect 
flags to ar have appeared in 3.3.2.


This looks like a bug to me...

--
Alan Burlison
--
--

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.4.1-1897-gf3ea5a5

[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  f3ea5a599f958e20a28e10365bc07253271cde04 (commit)
   via  3baca6364bb1569e6856337d80e54b37a96d017e (commit)
  from  ebf86b8bf65ec96e48f814d3f454106201df3538 (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=f3ea5a599f958e20a28e10365bc07253271cde04
commit f3ea5a599f958e20a28e10365bc07253271cde04
Merge: ebf86b8 3baca63
Author: Brad King 
AuthorDate: Mon Jan 11 10:18:43 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 11 10:18:43 2016 -0500

Merge topic 'mingw-clang-compile-features' into next

3baca636 Record compile features for MinGW Clang on Windows (#15897)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3baca6364bb1569e6856337d80e54b37a96d017e
commit 3baca6364bb1569e6856337d80e54b37a96d017e
Author: Brad King 
AuthorDate: Mon Jan 11 10:08:01 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 11 10:13:18 2016 -0500

Record compile features for MinGW Clang on Windows (#15897)

Drop the 'UNIX' condition on Clang compiler features.  This enables
use of compile features with MinGW Clang, though additional work may
be needed for clang-cl.

diff --git a/Help/release/dev/mingw-clang-compile-features.rst 
b/Help/release/dev/mingw-clang-compile-features.rst
new file mode 100644
index 000..5b1fb96
--- /dev/null
+++ b/Help/release/dev/mingw-clang-compile-features.rst
@@ -0,0 +1,5 @@
+mingw-clang-compile-features
+
+
+* The :manual:`Compile Features ` functionality
+  is now aware of features supported by Clang compilers on Windows (MinGW).
diff --git a/Modules/Compiler/Clang-CXX.cmake b/Modules/Compiler/Clang-CXX.cmake
index 6a0a5e2..dc62711 100644
--- a/Modules/Compiler/Clang-CXX.cmake
+++ b/Modules/Compiler/Clang-CXX.cmake
@@ -6,7 +6,7 @@ if(NOT "x${CMAKE_CXX_SIMULATE_ID}" STREQUAL "xMSVC")
 endif()
 
 cmake_policy(GET CMP0025 appleClangPolicy)
-if(WIN32 OR (APPLE AND NOT appleClangPolicy STREQUAL NEW))
+if(APPLE AND NOT appleClangPolicy STREQUAL NEW)
   return()
 endif()
 
@@ -49,7 +49,7 @@ macro(cmake_record_cxx_compile_features)
   endmacro()
 
   set(_result 0)
-  if (UNIX AND NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 3.4)
+  if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 3.4)
 _get_clang_features(${CMAKE_CXX14_STANDARD_COMPILE_OPTION} 
CMAKE_CXX14_COMPILE_FEATURES)
 if (_result EQUAL 0)
   _get_clang_features(${CMAKE_CXX11_STANDARD_COMPILE_OPTION} 
CMAKE_CXX11_COMPILE_FEATURES)

---

Summary of changes:
 Help/release/dev/mingw-clang-compile-features.rst |5 +
 Modules/Compiler/Clang-CXX.cmake  |4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)
 create mode 100644 Help/release/dev/mingw-clang-compile-features.rst


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

Re: [CMake] CMake incorrectly passes linker flags to ar

[Brad King]

On 01/11/2016 09:42 AM, Alan Burlison wrote:
> The "-m64" flag is used to tell the compiler/linker to create 64-bit 
> executables and is set via the following CMake variables:
> 
> CMAKE_EXE_LINKER_FLAGS
> CMAKE_SHARED_LINKER_FLAGS
> CMAKE_STATIC_LINKER_FLAGS

What is adding -m64 to CMAKE_STATIC_LINKER_FLAGS?  That value is indeed
meant to be used to pass flags to "ar" because CMake (for historical
reasons) abuses the term "linker" to refer to the archiver used for a
static library.

>set(CMAKE_CXX_ARCHIVE_CREATE " cq   
> ")
> 
> But I'm struggling to understand when passing in linker flags to ar 
> *ever* makes sense, at least on *nix platforms.

The name "LINK_FLAGS" is used as a placeholder there to share the
implementation with similar substitutions done in actual link line
generation.  See above about the naming.

The question here is what changed between 2.8.6 and 3.3.2 that causes
-m64 to start showing up in CMAKE_STATIC_LINKER_FLAGS.

-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

[CMake] FORTRAN name mangling

[Michael Jackson]

I am trying to integrate a FORTRAN library into our C++ project. I have
used the following in our CMakeLists.txt file:

include(CMakeAddFortranSubdirectory)

cmake_add_fortran_subdirectory(src
  NO_EXTERNAL_INSTALL
  PROJECT EMSoftLib  # project name in toplevel CMakeLists.txt in lapack
  LIBRARIES EMSoftLib # target libraries created
  LINK_LIBRARIES blas lapack # link interface libraries
  LINK_LIBS EMSoftLib blas lapack
)

include(FortranCInterface)
FortranCInterface_HEADER(EMsoftLib_Mangling.h MACRO_NAMESPACE "EMSOFTLIB_")

So far so good.

In the FORTRAN code we have the following declaration for a subroutine we
want to use from the "C" side of things:

subroutine SingleEBSDPattern(ipar, fpar, EBSDpattern, quats, accum_e,
mLPNH, mLPSH) bind(c, name='SingleEBSDPattern')

In order to access that function we created the following header file:


#include "EMsoftLib_Mangling.h"
#ifdef __cplusplus
extern "C" {
#endif
void EMSOFTLIB_GLOBAL(SingleEBSDPattern, SINGLEEBSDPATTERN)
(size_t* ipar, float* fpar, float* EBSDpattern,
float* quats, float* accum_e, float* mLPNH, float* mLPSH);
#ifdef __cplusplus
}
#endif

and we call the function from our C code like the following:


SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);

When we compile we get the following linker error:

MintDevVM:Build mdg$ make
[ 40%] Built target EMSoftLib
Scanning dependencies of target SingleEBSDPattern
[ 41%] Building CXX object
src/CMakeFiles/SingleEBSDPattern.dir/SingleEBSDPattern.cpp.o
[ 42%] Linking CXX executable ../Bin/SingleEBSDPattern
Undefined symbols for architecture x86_64:
  "_SingleEBSDPattern_", referenced from:
  _main in SingleEBSDPattern.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [Bin/SingleEBSDPattern] Error 1
make[1]: *** [src/CMakeFiles/SingleEBSDPattern.dir/all] Error 2
make: *** [all] Error 2

We can not seem to find any good examples of trying this sort of C->FORTRAN
interfacing with CMake besides http://www.kitware.com/blog/home/post/231

We are using gfortran 5.3 on OS X 10.10.5 with Xcode 7.2 tools.

Any insights would be most appreciated.

__
Mike Jackson  mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer  Dayton, Ohio
-- 

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.4.1-1902-g5c88b04

[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  5c88b0413cba78652e3f238302de04b10221c4a1 (commit)
   via  af39f11521af7fc2ec037103df1ad5a616dd7f19 (commit)
  from  e859349334c8e66148766e9f0acc82667a4944fd (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=5c88b0413cba78652e3f238302de04b10221c4a1
commit 5c88b0413cba78652e3f238302de04b10221c4a1
Merge: e859349 af39f11
Author: Brad King 
AuthorDate: Mon Jan 11 13:06:10 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 11 13:06:10 2016 -0500

Merge topic 'vs-global-properties' into next

af39f115 VS: Implement VS_GLOBAL_* target properties in VS 2010+ (#13666)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af39f11521af7fc2ec037103df1ad5a616dd7f19
commit af39f11521af7fc2ec037103df1ad5a616dd7f19
Author: Mike Fitzgerald 
AuthorDate: Fri Jan 8 17:33:28 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 11 13:04:34 2016 -0500

VS: Implement VS_GLOBAL_* target properties in VS 2010+ (#13666)

These have been documented but previously only implemented for VS 2008
and below.

diff --git a/Help/release/dev/vs-global-properties.rst 
b/Help/release/dev/vs-global-properties.rst
new file mode 100644
index 000..cae49b7
--- /dev/null
+++ b/Help/release/dev/vs-global-properties.rst
@@ -0,0 +1,5 @@
+vs-global-properties
+
+
+* The :prop_tgt:`VS_GLOBAL_` target property is now implemented
+  for VS 2010 and above.  Previously it worked only in VS 2008 and below.
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index 669c785..c9705ac 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -448,6 +448,32 @@ void cmVisualStudio10TargetGenerator::Generate()
 (*this->BuildFileStream) << cmVS10EscapeXML(targetFrameworkVersion)
  << "\n";
 }
+
+  std::vector keys = this->GeneratorTarget->GetPropertyKeys();
+  for(std::vector::const_iterator keyIt = keys.begin();
+  keyIt != keys.end(); ++keyIt)
+{
+static const char* prefix = "VS_GLOBAL_";
+if(keyIt->find(prefix) != 0)
+  continue;
+std::string globalKey = keyIt->substr(strlen(prefix));
+// Skip invalid or separately-handled properties.
+if(globalKey == "" ||
+   globalKey == "PROJECT_TYPES" ||
+   globalKey == "ROOTNAMESPACE" ||
+   globalKey == "KEYWORD")
+  {
+  continue;
+  }
+const char* value = this->GeneratorTarget->GetProperty(keyIt->c_str());
+if (!value)
+  continue;
+this->WriteString("<", 2);
+(*this->BuildFileStream) << globalKey << ">"
+ << cmVS10EscapeXML(value)
+ << "\n";
+}
+
   this->WriteString("\n", 1);
   this->WriteString("\n",

---

Summary of changes:
 Help/release/dev/vs-global-properties.rst  |5 +
 Source/cmVisualStudio10TargetGenerator.cxx |   26 ++
 2 files changed, 31 insertions(+)
 create mode 100644 Help/release/dev/vs-global-properties.rst


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

Re: [cmake-developers] VS_GLOBAL_ properties in VS 2010+ (was: patch building and testing)

[Brad King]

On 01/08/2016 05:56 PM, Mike Fitzgerald wrote:
> I've got the attached, which gives me the results I'd expect

Great, thanks.  I've applied this and merged to 'next' for testing:

 VS: Implement VS_GLOBAL_* target properties in VS 2010+ (#13666)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af39f115

> If I should be adding a test for this property

The property has an existing smoke test in Tests/VSResource but that
does not actually check that anything works.  The above-linked change
is acceptable on its own since the existing property was not tested
for VS 2008 and below even though it was implemented.  However, we'd
appreciate it if you could look at adding tests.

Take a look at

 Tests/RunCMake/XcodeProject
 Tests/RunCMake/SolutionGlobalSections

These directories have test cases that check the actual content of
the generated Xcode projects and VS .sln files.  Something similar
could be added to check for the results of this property in .vcxproj
files.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

[Pau Garcia i Quiles]

On Fri, Jan 8, 2016 at 5:30 PM, Brad King  wrote:


> See above.  Lua has come up several times in the past in particular because
> its implementation is meant to be small and embeddable.  I've thought a few
> times about how to make Lua scripting available from within the CMake
> language
> in a clean way, but that will not be as valuable as the above pure-spec
> approach.
>
>
Please, do not do that.

The moment you make CMake scriptable in more than one language, you are
forcing every CMake user to learn that additional language because sooner
or later he will step into a third-party that is using that additional
language.

IMHO, if you want Lua, then Lua it is. But then please get rid of CMake
scripting.

BTW, I am sure you are aware of CMakeScript, CMake scripting in JavaScript:

http://sourceforge.net/projects/cmakescript/

Also, declarative? Why? There are already a few declarative build systems
(e. g. qbs, one of the reasons for its existence was CMake was not
declarative). By moving CMake from the current procedural scripting to a
declarative approach, you may alienate your current user base and be good
for none anymore.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

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] FORTRAN name mangling

[Bill Somerville]

On 11/01/2016 17:58, Michael Jackson wrote:

and we call the function from our C code like the following:


SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);


You need to use the macros here too.

Regards
Bill Somerville.
--

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] FORTRAN name mangling

[Bill Somerville]

On 11/01/2016 18:48, Michael Jackson wrote:

Do other FORTRAN compilers support this “bind(C)” thing

I can only vouch for gfortran but yes that is the idea.

Regards
Bill Somerville.
--

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] Fwd: FindwxWidgets.cmake

[Simon Wells]

The following code is line 191-201, I have tested without this being set on
OSX 10.11 using system clang and both self-built and brew installed
wxwidgets with no problems, Whether its still an issue using gcc on osx or
some other configuration i am unsure, but is it worth being more specific
than just If APPLE for this bug-fix/workaround


# Using SYSTEM with INCLUDE_DIRECTORIES in conjunction with wxWidgets on
# the Mac produces compiler errors. Set wxWidgets_INCLUDE_DIRS_NO_SYSTEM
# to prevent UsewxWidgets.cmake from using SYSTEM.
#
# See cmake mailing list discussions for more info:
# https://cmake.org/pipermail/cmake/2008-April/021115.html
# https://cmake.org/pipermail/cmake/2008-April/021146.html
#
if(APPLE OR CMAKE_CXX_PLATFORM_ID MATCHES "OpenBSD")
set(wxWidgets_INCLUDE_DIRS_NO_SYSTEM 1)
endif()


thanks

Simon
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake incorrectly passes linker flags to ar

[Brad King]

On 01/11/2016 11:53 AM, Alan Burlison wrote:
> ISTR part of the issue at least was in the bowels of the CMake FindJNI 
> module, that makes extensive use of CMAKE_SYSTEM_PROCESSOR.

That is not representative of CMake in general.  If there is a better
way for FindJNI to get the information it needs then it would be great
to have needed changes contributed.

> The Hadoop CMakeLists.txt files don't use a PROJECT() command. The CMake 
> docs say if you don't do so then an implicit PROJECT() is added that 
> selects the C & C++ languages, is that done before processing any other 
> commands in CMakeLists.txt?

Yes, the implicit project() call is inserted on line zero of the top-level
CMakeLists.txt file.  This feature is meant to help people get started
with hello-world projects and is not meant for use by mature projects.
The top-level CMakeLists.txt file of a "real" project should start with

 cmake_minimum_required(VERSION ...)
 project(MyProject)

Flags affecting the target architecture are typically expected to be
provided by the user calling CMake, not by project code, and so will
be set before languages are enabled by this project() command.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] FORTRAN name mangling

[Michael Jackson]

Actually, 
  If we just use the following:

SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);

and the same declaration in a .h file then we can link and execute just fine. 
My question now would be:

Do other FORTRAN compilers support this “bind(C)” thing, such as Intel Fortran? 
If so then I can really NOT worry about figuring out the mangling that is 
needed and just declare the functions in a C style header like normal. No 
macros needed.
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net

> On Jan 11, 2016, at 1:13 PM, Bill Somerville  wrote:
> 
> On 11/01/2016 17:58, Michael Jackson wrote:
>> and we call the function from our C code like the following:
>> 
>> 
>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>> 
> You need to use the macros here too.
> 
> Regards
> Bill Somerville.
> -- 
> 
> 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] FORTRAN name mangling

[Bill Somerville]

On 11/01/2016 17:58, Michael Jackson wrote:
subroutine SingleEBSDPattern(ipar, fpar, EBSDpattern, quats, accum_e, 
mLPNH, mLPSH) bind(c, name='SingleEBSDPattern')


Surely if you use bind(C) you need do no more than extern "C" the 
declaration when compiling C++. I thought bind(C) meant mangle the 
external name in the same way that a C module would.


We use the FortranCInterface module for old Fortran procedures that are 
not using ISO_C_BINDING and bind(C), for them we add the symbols to the 
FortranCInterface_HEADER() command and use the generated macros to 
reference the symbols in C/C++.


We also execute FortranCInterface_VERIFY(CXX QUIET) before the 
FortranCInterface_HEADERS() command.


It all works OK but we only use gcc/g++/Clang/Clang++/gfortran compilers.

Regards
Bill Somerville.
--

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.4.1-1905-g8673afc

[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  8673afc72a2ba9ba8d7184411b4b1247ea45d774 (commit)
   via  a57caf7eecdfe61e4ac5f63b145fc9269610f3f0 (commit)
   via  ad594de8cc9c4063830df58453b0679c209ff4d8 (commit)
  from  5c88b0413cba78652e3f238302de04b10221c4a1 (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=8673afc72a2ba9ba8d7184411b4b1247ea45d774
commit 8673afc72a2ba9ba8d7184411b4b1247ea45d774
Merge: 5c88b04 a57caf7
Author: Brad King 
AuthorDate: Mon Jan 11 13:56:25 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 11 13:56:25 2016 -0500

Merge topic 'vs-win10-sdk' into next

a57caf7e VS: Fix Windows 10 SDK version selection (#15831)
ad594de8 cmSystemTools: Add VersionCompareEqual helper


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a57caf7eecdfe61e4ac5f63b145fc9269610f3f0
commit a57caf7eecdfe61e4ac5f63b145fc9269610f3f0
Author: Brad King 
AuthorDate: Mon Jan 11 13:44:11 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 11 13:44:11 2016 -0500

VS: Fix Windows 10 SDK version selection (#15831)

In commit v3.4.0-rc1~5^2~1 (VS: Add support for selecting the Windows 10
SDK, 2015-09-30) we added Windows 10 SDK selection choosing the most
recent SDK that is not newer than the target version.  This is backward
because it should be up to the application code to not use APIs newer
than the target version.  It is up to the build system to provide a SDK
that has at least the APIs expected to be available for the target
version.  Furthermore, since the default target version is the host
version of Windows, the old approach breaks when the only SDK available
is for a newer version of Windows.

Fix this by always selecting a Windows 10 SDK if one exists.  Use the
SDK for the exact version if is available.  Otherwise use the latest
version of the SDK available because that will have at least the APIs
expected for the target version.

diff --git a/Source/cmGlobalVisualStudio14Generator.cxx 
b/Source/cmGlobalVisualStudio14Generator.cxx
index 803b500..83499f1 100644
--- a/Source/cmGlobalVisualStudio14Generator.cxx
+++ b/Source/cmGlobalVisualStudio14Generator.cxx
@@ -277,29 +277,21 @@ std::string 
cmGlobalVisualStudio14Generator::GetWindows10SDKVersion()
   *i = cmSystemTools::GetFilenameName(*i);
   }
 
-// Sort the results to make sure we select the most recent one that
-// has a version less or equal to our version of the operating system
+// Sort the results to make sure we select the most recent one.
 std::sort(sdks.begin(), sdks.end(), cmSystemTools::VersionCompareGreater);
 
-// Select a suitable SDK version.
-if (this->SystemVersion == "10.0")
-  {
-  // Use the latest Windows 10 SDK since no build version was given.
-  return sdks.at(0);
-  }
-else
+// Look for a SDK exactly matching the requested target version.
+for (std::vector::iterator i = sdks.begin();
+ i != sdks.end(); ++i)
   {
-  // Find the SDK less or equal to our specified version
-  for (std::vector::iterator i = sdks.begin();
-   i != sdks.end(); ++i)
+  if (cmSystemTools::VersionCompareEqual(*i, this->SystemVersion))
 {
-if (!cmSystemTools::VersionCompareGreater(*i, this->SystemVersion))
-  {
-  // This is the most recent SDK that we can run safely
-  return *i;
-  }
+return *i;
 }
   }
+
+// Use the latest Windows 10 SDK since the exact version is not available.
+return sdks.at(0);
 }
 #endif
   // Return an empty string

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad594de8cc9c4063830df58453b0679c209ff4d8
commit ad594de8cc9c4063830df58453b0679c209ff4d8
Author: Brad King 
AuthorDate: Mon Jan 11 13:42:07 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 11 13:43:22 2016 -0500

cmSystemTools: Add VersionCompareEqual helper

Wrap a call to VersionCompare with OP_EQUAL.

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 2c5aa8a..d8b8415 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2777,6 +2777,14 @@ bool 
cmSystemTools::VersionCompare(cmSystemTools::CompareOp op,
 }
 
 //
+bool cmSystemTools::VersionCompareEqual(std::string const& lhs,
+

Re: [CMake] FORTRAN name mangling

[Thompson, KT]

"bind(c)" is a part of the Fortran 2003 standard.  Any compiler that claims to 
support this standard should work for you.

I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue.  FWIW - I also 
use the Portland Group (12+) and IBM Fortran (v14) compilers this way.

-kt

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Jackson
Sent: Monday, January 11, 2016 11:48 AM
To: Bill Somerville 
Cc: cmake@cmake.org
Subject: Re: [CMake] FORTRAN name mangling

Actually, 
  If we just use the following:

SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);

and the same declaration in a .h file then we can link and execute just fine. 
My question now would be:

Do other FORTRAN compilers support this “bind(C)” thing, such as Intel Fortran? 
If so then I can really NOT worry about figuring out the mangling that is 
needed and just declare the functions in a C style header like normal. No 
macros needed.
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net

> On Jan 11, 2016, at 1:13 PM, Bill Somerville  wrote:
> 
> On 11/01/2016 17:58, Michael Jackson wrote:
>> and we call the function from our C code like the following:
>> 
>> 
>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>> 
> You need to use the macros here too.
> 
> Regards
> Bill Somerville.
> -- 
> 
> 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
-- 

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] FORTRAN name mangling

[Damian Rouson]

> On Jan 11, 2016, at 11:31 AM, Zaak Beekman  wrote:
> 
> 
> So if I require Fortran 2003 for our fortran codes then this whole ?fortran 
> name-mangling? thing becomes a moot point, i.e. I do not have to actually 
> worry about it at all for our project. Just have to keep the C header 
> consistent with the FORTRAN functions, but that part is on our devs.
> 
> Exactly, that is the whole point of the standardized `ISO_C_BINDING` module 
> and C interop being added to the Fortran 2003 standard. No more ugly guess 
> work, hackery, etc.
> 
> AFAIK, there is pretty good support for this among compiler vendors, so long 
> as you have a recent release.

Even as far back as about five years ago, all 10 compilers surveyed by Ian 
Chivers and Jane Sleightholme supported C interoperability.  And now there are 
at least four compilers that even support the _additional_ C interoperability 
features in the draft Fortran 2015 standard: the IBM, Cray, Intel, and GNU 
compilers.  C interoperability appears to be one of the first things every 
compiler team tackles from a new standard.

Anyone with access to ACM Fortran Forum will benefit from consulting the 
standards-support survey that Ian and Jane have published in almost every issue 
for roughly a decade or so.  Standards support in  Fortran compilers is not 
quite where it needs to be, but it’s much better than it was even just a couple 
of years ago. Great strides have been taken.

> I know for sure GCC's gfortran and Intel's ifort support this very well. I'm 
> pretty sure PGI, Cray and IBM support it too. I have never used NAG, so I 
> withhold comment there, but I'd be surprised if they had yet to add this to 
> their compiler. The demand for C interop is really high, and almost all of 
> these companies make companion C compilers, so, in my experience, they have 
> been relatively quick to implement these features, while some other Fortran 
> 2003 and later features have languished. (I'm looking at you, parameterized 
> derived types…)

PDT is one of the few Fortran 2003 features for which support is still a bit 
limited, but it is supported by at lest four compilers: IBM, Cray, Intel, and 
Portland Group, all of which are fully Fortran 2003 compliant.  I would bet 
that NAG will have it soon and GNU will likely have it in their development 
branch sometime later this year.  A developer has already put a great deal of 
work into scoping out the effort.  PDTs are a monster to implement in a 
compiler.

> 
> P.S. Unless you want to sound like an old geezer, it's spelled Fortran these 
> days, not FORTRAN. ;-)

And the standard has spelled it in mixed case at least since Fortran 90 so, in 
addition to being dated, spelling FORTRAN in all-caps is non-standard. 

:D

-- 

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] FORTRAN name mangling

[Thompson, KT]

Michael,

You should always test your toolchain first.  Compilers are often buggy or may 
not fully support a language feature.  But yes, requiring F2003 should address 
your concern.

-kt

-Original Message-
From: Michael Jackson [mailto:mike.jack...@bluequartz.net] 
Sent: Monday, January 11, 2016 12:11 PM
To: Thompson, KT 
Cc: cmake@cmake.org
Subject: Re: [CMake] FORTRAN name mangling

So if I require Fortran 2003 for our fortran codes then this whole “fortran 
name-mangling” thing becomes a moot point, i.e. I do not have to actually worry 
about it at all for our project. Just have to keep the C header consistent with 
the FORTRAN functions, but that part is on our devs.

--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net

> On Jan 11, 2016, at 2:06 PM, Thompson, KT  wrote:
> 
> "bind(c)" is a part of the Fortran 2003 standard.  Any compiler that claims 
> to support this standard should work for you.
> 
> I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue.  FWIW - I also 
> use the Portland Group (12+) and IBM Fortran (v14) compilers this way.
> 
> -kt
> 
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Jackson
> Sent: Monday, January 11, 2016 11:48 AM
> To: Bill Somerville 
> Cc: cmake@cmake.org
> Subject: Re: [CMake] FORTRAN name mangling
> 
> Actually, 
>  If we just use the following:
> 
> SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
> 
> and the same declaration in a .h file then we can link and execute just fine. 
> My question now would be:
> 
> Do other FORTRAN compilers support this “bind(C)” thing, such as Intel 
> Fortran? If so then I can really NOT worry about figuring out the mangling 
> that is needed and just declare the functions in a C style header like 
> normal. No macros needed.
> --
> Michael A. Jackson
> BlueQuartz Software, LLC
> [e]: mike.jack...@bluequartz.net
> 
>> On Jan 11, 2016, at 1:13 PM, Bill Somerville  wrote:
>> 
>> On 11/01/2016 17:58, Michael Jackson wrote:
>>> and we call the function from our C code like the following:
>>> 
>>> 
>>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>>> 
>> You need to use the macros here too.
>> 
>> Regards
>> Bill Somerville.
>> -- 
>> 

-- 

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] FORTRAN name mangling

[Zaak Beekman]

> So if I require Fortran 2003 for our fortran codes then this whole
> ?fortran name-mangling? thing becomes a moot point, i.e. I do not have to
> actually worry about it at all for our project. Just have to keep the C
> header consistent with the FORTRAN functions, but that part is on our devs.
>

Exactly, that is the whole point of the standardized `ISO_C_BINDING` module
and C interop being added to the Fortran 2003 standard. No more ugly guess
work, hackery, etc.

AFAIK, there is pretty good support for this among compiler vendors, so
long as you have a recent release. I know for sure GCC's gfortran and
Intel's ifort support this very well. I'm pretty sure PGI, Cray and IBM
support it too. I have never used NAG, so I withhold comment there, but I'd
be surprised if they had yet to add this to their compiler. The demand for
C interop is really high, and almost all of these companies make companion
C compilers, so, in my experience, they have been relatively quick to
implement these features, while some other Fortran 2003 and later features
have languished. (I'm looking at you, parameterized derived types...)

Happy hacking!

P.S. Unless you want to sound like an old geezer, it's spelled Fortran
these days, not FORTRAN. ;-)
-- 

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] FORTRAN name mangling

[Michael Jackson]

So if I require Fortran 2003 for our fortran codes then this whole “fortran 
name-mangling” thing becomes a moot point, i.e. I do not have to actually worry 
about it at all for our project. Just have to keep the C header consistent with 
the FORTRAN functions, but that part is on our devs.

--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net

> On Jan 11, 2016, at 2:06 PM, Thompson, KT  wrote:
> 
> "bind(c)" is a part of the Fortran 2003 standard.  Any compiler that claims 
> to support this standard should work for you.
> 
> I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue.  FWIW - I also 
> use the Portland Group (12+) and IBM Fortran (v14) compilers this way.
> 
> -kt
> 
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Jackson
> Sent: Monday, January 11, 2016 11:48 AM
> To: Bill Somerville 
> Cc: cmake@cmake.org
> Subject: Re: [CMake] FORTRAN name mangling
> 
> Actually, 
>  If we just use the following:
> 
> SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
> 
> and the same declaration in a .h file then we can link and execute just fine. 
> My question now would be:
> 
> Do other FORTRAN compilers support this “bind(C)” thing, such as Intel 
> Fortran? If so then I can really NOT worry about figuring out the mangling 
> that is needed and just declare the functions in a C style header like 
> normal. No macros needed.
> --
> Michael A. Jackson
> BlueQuartz Software, LLC
> [e]: mike.jack...@bluequartz.net
> 
>> On Jan 11, 2016, at 1:13 PM, Bill Somerville  wrote:
>> 
>> On 11/01/2016 17:58, Michael Jackson wrote:
>>> and we call the function from our C code like the following:
>>> 
>>> 
>>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>>> 
>> You need to use the macros here too.
>> 
>> Regards
>> Bill Somerville.
>> -- 
>> 

-- 

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 based package manager

[Nicholas Braden]

Hh, sorry, I should have found that myself! This definitely looks
interesting, and I agree that not requiring an external program like
Biicode is a good idea. Thanks for sharing this, I will try it out
when I have time :)

On Mon, Jan 11, 2016 at 7:40 AM, Cristian Adam  wrote:
> On Mon, Jan 11, 2016 at 2:33 PM, Nicholas Braden
>  wrote:
>>
>> Doesn't biicode already fill this role? Biicode seems to work well
>> enough for me, anyway.
>>
>
> Biicode is dead.
>
> There is a comparison with biicode here:
> https://github.com/ruslo/hunter/issues/54
>
> Having only CMake as a dependency is awesome!
>
> I have tried once to reuse biicode's OpenSSL CMake files, I failed. So I
> ended up
> using perl and whatever OpenSSL needed to compile.
>
> On the other hand hunter has only CMake as dependency, which means that its
> CMake scripts are very portable.
>
> Cheers,
> Cristian.
>
>
-- 

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] FORTRAN name mangling

[Bill Hoffman]

On 1/11/2016 2:31 PM, Zaak Beekman wrote:

Happy hacking!

FYI:
There is a longer version of that blog found here:
http://www.netlib.org/lapack/lawnspdf/lawn270.pdf
bind(c) sounds like a good idea if your compilers support it.

-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