[CMake] Patch for CM_OVERRIDE

[Roman Wüger]

Hello,

I've attached a patch for the CM_OVERRIDE commit

Best Regards
Roman



0001-fixup-CM_OVERRIDE-Visual-Studio-2010-and-below-do-no.patch
Description: Binary data

-- 

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.6.0-rc3-276-gb9b3ec4

[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  b9b3ec4d98b03c180b2e6b9ad8edba7f75576353 (commit)
  from  4bbfea17510d25c950747c4b0f877e5d5b1f528e (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=b9b3ec4d98b03c180b2e6b9ad8edba7f75576353
commit b9b3ec4d98b03c180b2e6b9ad8edba7f75576353
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Jun 29 00:01:05 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Jun 29 00:01:05 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4e2ea58..9d2e2d4 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 6)
-set(CMake_VERSION_PATCH 20160628)
+set(CMake_VERSION_PATCH 20160629)
 #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] How do you handle recursive dependencies in CMake

[Raymond Wan]

On Wed, Jun 29, 2016 at 3:23 AM, Cfyz  wrote:
> On 28 June 2016 at 17:19, Raymond Wan  wrote:
>> I think if I were presented with the same problem as Sven, I'd <...> Or,
>> if that wasn't possible, use ExternalProject.
>> It's inefficient in terms of disk space, but at least A (assuming A
>> depends on B) will be built correctly.
> What I'm trying to solve (and what Sven's problem looks very similar to) is
> more about keeping the information about dependencies. You've mentioned that
> yourself in the linked discussion: the real problem are projects with
> complex tree-like dependencies, more than one edge deep. And once those
> dependencies become optional and configurable, things break completely. It
> is impossible to search for the dependency you don't even know about =(.


I agree that what we're observing is a problem, but I don't think it
is that big.  There are at least 3 solutions discussed so far:

1)  The "ad-hoc" method I first mentioned by setting
CMAKE_LIBRARY_OUTPUT_DIRECTORY.
2)  ExternalProject which will grab a repository and build it.
3)  Some Find_Package () mechanism that will do a search for it.
4)  Your option of including *.cmake files that provide the paths
[sorry, I might have misunderstood it].

If we have some kind of transitive dependency:  A depends on B; B depends on C.

Then when we build A, we don't really need to know [in detail] that
this transitive dependency exists (*).  All the compiler needs to know
is where is B and where is C.  And if B and C are in the same
directory (i.e., a system-level directory), that's fine.

Suppose B and C are in two different directories.  I don't know if
it's common, but often, I see install scripts provide a symbolic link
from the system-level directory to where B and C are

In Sven's case (sorry to put you on the spot, Sven!  :-) ), the 3
options don't work because:

1)  Modules are in different source trees.
2)  Duplication between users on a super-computer.
3)  Too many combinations of Find_Package ().
4)  Seems ad-hoc?

Though not perfect, either (2) or (3) could solve Sven's problem.  For
(2), ignore duplication.  For (3), how about something like what
Find_Boost does?  It searches for system-level directories, but you
can nudge it by setting an environment variable (i.e., BOOST_ROOT)
where it will search first.  This means each user will have to set an
environment variable (or set it on the command-line of CMake with -D).

Hm, I *think* any of this is fine (for Sven's problem), but if it
isn't then perhaps I'm misunderstanding the problem...

Ray

(*)  At least, the order to the archives in target_link_libraries have
to be correct.  But that is done once by the CMakeLists.txt writer and
not something the end user needs to worry about.
-- 

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] [iOS] What is the correct way to add resources to an XCode project

[Ruslan Baratov via CMake]

Hi,

I have used two approaches which is not based on assets directories.

First is to save icons to resources with special names. In this case 
Xcode will add them automatically, see:
* 
https://github.com/forexample/testapp/blob/9202304134862f043af740af27dc7efb3b3f565d/CMakeLists.txt#L28


Second is to save icons to resources too, but you can control names of 
pictures. You have to update *.plist file in this case.
* custom names: 
https://github.com/ruslo/weather/blob/56eee62eaac327e1a048165aaa868c2f3a71972f/Source/weather/ui/ios/icons/app/sugar.cmake#L15
* plist file: 
https://github.com/ruslo/weather/blob/56eee62eaac327e1a048165aaa868c2f3a71972f/Source/weather/ui/ios/views/plist.in#L35
* adding to resources: 
https://github.com/ruslo/weather/blob/56eee62eaac327e1a048165aaa868c2f3a71972f/Source/weather/ui/ios/CMakeLists.txt#L49


Also according to my reverse engineering skills next xcode variables 
used to define assets directories for icons and launch images:

* ASSETCATALOG_COMPILER_APPICON_NAME
* ASSETCATALOG_COMPILER_LAUNCHIMAGE_NAME

This means you can experiment with target properties:
* XCODE_ATTRIBUTE_ASSETCATALOG_COMPILER_APPICON_NAME
* XCODE_ATTRIBUTE_ASSETCATALOG_COMPILER_LAUNCHIMAGE_NAME

I have never used them before, so have no idea about it's working or not.

Ruslo

On 29-Jun-16 00:01, Roman Wüger wrote:

No one?

The target property RESOURCE does only allow files but no directories.

Regards
Roman



Am 22.06.2016 um 17:22 schrieb Roman Wüger :

Hello,

I read the mailing list but did find a way which works.

At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for iOS 
9.3.

All I want is to add the directory "Images.xcassets" and a second directory 
structure to be copied to the Resource folder listed in XCode.

When I manually drag'n drop the directories into the Resource folder as 
reference or as group everything is working. How can I archive this with CMake?

Thanks and regards
Roman
--

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

[CMake] CMAKE_C_COMPILE_OBJECT vs

[Sam Cristall]

I'm trying to implement a cross compilation wrapper and hit a snag with 
CMAKE_C_COMPILE_OBJECT.  I've found that on OSX / Linux (Makefile Generator), 
 and  work as expected, however on Windows (MinGW Makefile 
Generator),  has both the flags and includes, whereas  is 
undefined.  Is this expected?


Sam Cristall, BSc. EE
Director, R
skype: sam.cristall
phone: +1-780-292-0423 <>

Eleven Engineering Inc.
10150 100 st, Suite 800
Edmonton, Alberta 
Canada, T5J 0P6

-- 

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] daemon-mode meeting last Tuesday

[Stephen Kelly]

Tobias Hunger wrote:

> Hello CMake Developers,
> 
> Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch
> we both have been working on. It was a very productive meeting: We managed
> to resolve almost all the differences of opinion we had.

Thanks Tobias for the summary and everyone else for the discussion.

Here are a few additional notes that I took when meeting Tobias last week. 
These notes don't change anything in the discussion, but expands on a few 
things to put some meat on the bones and lists some discarded design 
options.

cmMessenger
---

> * Having cmMessanger would be nice and will make things easier.

In particular - a cmMessenger class can have some virtual methods 
implemented to print to the console as cmake::IssueMessage currently does. 

It would be inherited by a cmServerMessenger which would override the 
virtual methods to send them over the server IPC protocol instead of 
printing them on stdout. This has the advantage of not losing semantic 
information - a backtrace becomes a JSON array, meaning clients don't have 
to try to parse the backtrace out of the stdout message as they currently 
do. That becomes possible with just a IssueMessage virtual. See 

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607

Additionally, the cmMessenger can have additional high-level virtual 
methods, such as for find_package results making it easier for user tools 
and IDEs to get a list of packages searched for and make it possible to give 
users use-case specific ways of specifying where packages are.

Similarly it can have a virtual method for try_compile results (somehow - 
this might require extending the message type for scripting API) which also 
give user tools more opportunities to present the user with semantic 
information and not discard the intent of the person writing the 
buildsystem.

Another place where a virtual method on cmMessenger would make sense is for 
policy warnings, giving user tools a chance to present them to the user 
without trying to parse them from stdout.

There may be other messages which have semantics whose meaning we currently 
discard by printing to stdout.

All of this is currently blocked by a clean-up in the parser needing further 
review and perhaps further implementation work:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=16663


Name


Last year before publication I was calling this feature a 'metadata server' 
(class called cmMetadataServer etc). I probably made a mistake renaming it 
to a daemon. Now, 'metadata server' might be better and more specific than 
'server' alone.

Change Notification
---

I wrote previously that I think change notification is an essential feature 
of the first version of the protocol - otherwise the output is no better 
than a static generated file. 

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16589/focus=16648

Tobias was concerned that implementing filesystem watching for all necessary 
platforms is an unreasonable burden and he would prefer something like 
QFileSystemWatcher.

libuv has a portable abstraction for filesystem change notification similar 
in a way to QFileSystemWatcher. I implemented a basic use of the libuv API 
fs notification API last year.

Action item for me is to dig out that work or do it again. Then the metadata 
server can emit a message on the protocol when the source directory content 
changes.

Feature Flags
-

> 1.2 Protocol versions
> 
> * We need the daemon-mode to support different protocol versions.
> 
> * We want to have the option to mark protocol versions as experimental.

As far as I know, Chrome has a development model whereby unfinished features 
are checked into master immediately and developed there, instead of being 
developed in a branch. The new/experimental features are disabled by default 
with 'feature flags' so that people/CI can enable and test features which 
are candidates to be enabled by default to everyone.

We discussed whether this would make sense for the server instead of 
'experimental' protocol versions. We decided that such feature flags would 
make sense if there would be many experimental features in flight from 
multiple contributors over multiple cmake releases. We don't expect this to 
be the case, so we consider feature flags to be over-engineered for the 
server for now.

InReplyTo
-

> * Currently a reply (and error and all other messages in response to a
> request) contain a "inReplyTo" with the type string from the request
> triggering the reply.
> 
> Stephen thinks that is not necessary and argues anything that is not
> strictly necessary should not be in the first version of the protocol.

Tobias told me that the only reason for this is to make it easier for people 
developing the actual protocol to paste blocks of text which contain 
multiple server messages. For example a developer could paste a 

Re: [CMake] Dependency on imported target with ninja-generator

[Patrick Boettcher]

On Wed, 22 Jun 2016 19:44:14 -0500
Nicholas Braden  wrote:

> If Project B depends on Project A, you should probably be using the
> ExternalProject module with a superproject structure that builds both
> projects in the proper order.
> 
> https://cmake.org/cmake/help/latest/module/ExternalProject.html
> 
> Trying to manually call CMake is not really a good idea IMO - let
> ExternalProject handle it for you.

That was it: superproject - based on CMake + ExternalProject.

Thanks a lot.

Regards,
--
Patrick.
-- 

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] Script to update liblzma from upstream.

[Daniel Pfeifer]

Hi Brad,

I have attached a patch that adds a script to update liblzma from
upstream (closely modeled after the other update scripts).  I am not
sure how these kinds of scripts need to be run.

We currently have a copy of liblzma version 5.0.5. The latest version
on the 5.0 branch is 5.0.8. Once the script is introduced, we may
consider switching to the 5.2 branch.

Cheers, Daniel
From c0401e6f56fe5c9c77e9a80a2c2ab063930f70ed Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer 
Date: Tue, 28 Jun 2016 23:10:11 +0200
Subject: [PATCH] Add script to update liblzma from upstream

---
 Utilities/Scripts/update-liblzma.bash | 29 +
 1 file changed, 29 insertions(+)
 create mode 100755 Utilities/Scripts/update-liblzma.bash

diff --git a/Utilities/Scripts/update-liblzma.bash b/Utilities/Scripts/update-liblzma.bash
new file mode 100755
index 000..4933017
--- /dev/null
+++ b/Utilities/Scripts/update-liblzma.bash
@@ -0,0 +1,29 @@
+#!/usr/bin/env bash
+
+set -e
+set -x
+shopt -s dotglob
+
+readonly name="liblzma"
+readonly ownership="liblzma upstream "
+readonly subtree="Utilities/cmliblzma"
+readonly repo="http://git.tukaani.org/xz.git;
+readonly tag="v5.0"
+readonly shortlog=false
+readonly paths="
+  src/common/sysdefs.h
+  src/common/tuklib_integer.h
+  src/liblzma
+  COPYING
+"
+
+extract_source () {
+git_archive
+pushd "${extractdir}/${name}-reduced"
+mv src/common .
+mv src/liblzma .
+rmdir src
+popd
+}
+
+. "${BASH_SOURCE%/*}/update-third-party.bash"
-- 
2.9.0

-- 

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] [iOS] What is the correct way to add resources to an XCode project

[Roman Wüger]

No one?

The target property RESOURCE does only allow files but no directories.

Regards
Roman


> Am 22.06.2016 um 17:22 schrieb Roman Wüger :
> 
> Hello,
> 
> I read the mailing list but did find a way which works.
> 
> At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for 
> iOS 9.3.
> 
> All I want is to add the directory "Images.xcassets" and a second directory 
> structure to be copied to the Resource folder listed in XCode.
> 
> When I manually drag'n drop the directories into the Resource folder as 
> reference or as group everything is working. How can I archive this with 
> CMake?
> 
> Thanks and regards
> Roman
> -- 
> 
> 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-developers

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-590-gc664b95

[Daniel Pfeifer]

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  c664b95b08f793808d881ed08919bfa1a7fce409 (commit)
   via  f05f5b01d0a690e5f3e06be2c702ee659433c326 (commit)
  from  0172bc17b57d7a0b7b3a244124b41cb71cdbc4fa (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=c664b95b08f793808d881ed08919bfa1a7fce409
commit c664b95b08f793808d881ed08919bfa1a7fce409
Merge: 0172bc1 f05f5b0
Author: Daniel Pfeifer 
AuthorDate: Tue Jun 28 17:06:15 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 17:06:15 2016 -0400

Merge topic 'cmliblzma-static' into next

f05f5b01 cmliblzma: always build as static library


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f05f5b01d0a690e5f3e06be2c702ee659433c326
commit f05f5b01d0a690e5f3e06be2c702ee659433c326
Author: Daniel Pfeifer 
AuthorDate: Tue Jun 28 23:05:37 2016 +0200
Commit: Daniel Pfeifer 
CommitDate: Tue Jun 28 23:05:37 2016 +0200

cmliblzma: always build as static library

diff --git a/Utilities/cmliblzma/CMakeLists.txt 
b/Utilities/cmliblzma/CMakeLists.txt
index 8920536..e806680 100644
--- a/Utilities/cmliblzma/CMakeLists.txt
+++ b/Utilities/cmliblzma/CMakeLists.txt
@@ -182,10 +182,6 @@ SET(LZMA_SRCS
   liblzma/simple/x86.c
   )
 
-IF(WIN32 AND BUILD_SHARED_LIBS)
-  SET(LZMA_SRCS ${LZMA_SRCS} liblzma/liblzma_w32res.rc)
-ENDIF()
-
 CONFIGURE_FILE(config.h.in config.h @ONLY)
 
 INCLUDE_DIRECTORIES(
@@ -209,7 +205,7 @@ ELSEIF(CMAKE_C_COMPILER_ID STREQUAL "PathScale")
   SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -woffall")
 ENDIF()
 
-ADD_LIBRARY(cmliblzma ${LZMA_SRCS})
+ADD_LIBRARY(cmliblzma STATIC ${LZMA_SRCS})
 
 IF(CMAKE_C_COMPILER_ID STREQUAL "XL")
   # Disable the XL compiler optimizer because it causes crashes

---

Summary of changes:
 Utilities/cmliblzma/CMakeLists.txt |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)


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

Re: [CMake] [iOS] What is the correct way to add resources to an XCode project

[Roman Wüger]

No one?

The target property RESOURCE does only allow files but no directories.

Regards
Roman


> Am 22.06.2016 um 17:22 schrieb Roman Wüger :
> 
> Hello,
> 
> I read the mailing list but did find a way which works.
> 
> At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for 
> iOS 9.3.
> 
> All I want is to add the directory "Images.xcassets" and a second directory 
> structure to be copied to the Resource folder listed in XCode.
> 
> When I manually drag'n drop the directories into the Resource folder as 
> reference or as group everything is working. How can I archive this with 
> CMake?
> 
> Thanks and regards
> Roman
> -- 
> 
> 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] How do you handle recursive dependencies in CMake

[Cfyz]

Hello Sven, Raymond.

On 28 June 2016 at 16:07, Sven Baars  wrote:
> Hence my question if there is some "right" way of doing this with CMake,
without all of the code I wrote to work around the problem.

I am under impression there is an important bit missing from CMake export
system. If some library has an unspecified set of dependencies (decided
during its configuration) then it will not be able to generate a config
file for find_package with CMake default tools alone. I think I will raise
it as an issue at the main CMake issue tracker after some more
investigation.


On 28 June 2016 at 16:07, Sven Baars  wrote:
> I also wrote a lot of homebrew code you mentioned at the end of the post,
but it indeed always seems to always break something for some user of the
code
> In the mean time I'll have a look at the code you wrote, but it seems
very similar to something I already had, which broke for some users.

The code examples and what I've mentioned earlier are just pieces of the
possible solution. A complete export has a lot of nuances (e. g.
versioning, build configurations, etc.) and is unlikely to work flawlessly
right from the start. But think it might be worthwhile to try and make such
helper module somewhere on github.


On 28 June 2016 at 17:19, Raymond Wan  wrote:
> I think if I were presented with the same problem as Sven, I'd <...> Or,
if that wasn't possible, use ExternalProject.
> It's inefficient in terms of disk space, but at least A (assuming A
depends on B) will be built correctly.

What I'm trying to solve (and what Sven's problem looks very similar to) is
more about keeping the information about dependencies. You've mentioned
that yourself in the linked discussion: the real problem are projects with
complex tree-like dependencies, more than one edge deep. And once those
dependencies become optional and configurable, things break completely. It
is impossible to search for the dependency you don't even know about =(.

ExternalProject has a somewhat similar flaw. I've tried once to use it for
FFmpeg and found out that ExternalProject does its work at the build step.
On the configure step there is nothing yet and consequently there is no way
to figure out what will be needed to link against the library. Even though
FFmpeg does report its dependencies (via pkg-config) later after being
installed, it is too late. There was a workaround with two-step build but
that looked ugly, scaled even worse and I've settled on separate builds and
custom find modules.
-- 

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.6.0-rc3-588-g0172bc1

[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  0172bc17b57d7a0b7b3a244124b41cb71cdbc4fa (commit)
   via  943fe6e3b40cde7eb927bb2e2acf049fe580c188 (commit)
  from  29f8f5f6c24a1f513644c564098ba5be09cd33f0 (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=0172bc17b57d7a0b7b3a244124b41cb71cdbc4fa
commit 0172bc17b57d7a0b7b3a244124b41cb71cdbc4fa
Merge: 29f8f5f 943fe6e
Author: Brad King 
AuthorDate: Tue Jun 28 15:09:39 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 15:09:39 2016 -0400

Merge topic 'revert-try_compile-config-flags' into next

943fe6e3 Revert "try_compile: Honor CMAKE__FLAGS_ changes"


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=943fe6e3b40cde7eb927bb2e2acf049fe580c188
commit 943fe6e3b40cde7eb927bb2e2acf049fe580c188
Author: Brad King 
AuthorDate: Tue Jun 28 15:03:00 2016 -0400
Commit: Brad King 
CommitDate: Tue Jun 28 15:03:45 2016 -0400

Revert "try_compile: Honor CMAKE__FLAGS_ changes"

Revert commit v3.6.0-rc1~160^2 (try_compile: Honor
CMAKE__FLAGS_ changes, 2016-04-11).  The behavior it
introduced can break projects that depend on the lack of such behavior.
We will have to introduce a policy or other mechanism to enable the
behavior in a compatible way.  Simply revert it for now.

See issue #16174.

diff --git a/Help/release/3.6.rst b/Help/release/3.6.rst
index 5c08b39..771c9dd 100644
--- a/Help/release/3.6.rst
+++ b/Help/release/3.6.rst
@@ -42,11 +42,6 @@ Commands
   commands gained support for the ``%s`` placeholder.  This is
   the number of seconds since the UNIX Epoch.
 
-* The :command:`try_compile` command source file signature now honors
-  configuration-specific flags (e.g. :variable:`CMAKE__FLAGS_DEBUG`)
-  in the generated test project.  Previously only the default such flags
-  for the current toolchain were used.
-
 Variables
 -
 
diff --git a/Source/cmCoreTryCompile.cxx b/Source/cmCoreTryCompile.cxx
index 0149fdf..75d0e9e 100644
--- a/Source/cmCoreTryCompile.cxx
+++ b/Source/cmCoreTryCompile.cxx
@@ -333,14 +333,6 @@ int 
cmCoreTryCompile::TryCompileCode(std::vector const& argv,
   fprintf(fout, "set(CMAKE_%s_FLAGS \"${CMAKE_%s_FLAGS}"
 " ${COMPILE_DEFINITIONS}\")\n",
   li->c_str(), li->c_str());
-  static std::string const cfgDefault = "DEBUG";
-  std::string const cfg =
-!tcConfig.empty() ? cmSystemTools::UpperCase(tcConfig) : cfgDefault;
-  std::string const langFlagsCfg = "CMAKE_" + *li + "_FLAGS_" + cfg;
-  const char* flagsCfg = this->Makefile->GetDefinition(langFlagsCfg);
-  fprintf(
-fout, "set(%s %s)\n", langFlagsCfg.c_str(),
-cmOutputConverter::EscapeForCMake(flagsCfg ? flagsCfg : "").c_str());
 }
 switch (this->Makefile->GetPolicyStatus(cmPolicies::CMP0056)) {
   case cmPolicies::WARN:
diff --git a/Tests/RunCMake/try_compile/CompileFlags.cmake 
b/Tests/RunCMake/try_compile/CompileFlags.cmake
deleted file mode 100644
index d4dc074..000
--- a/Tests/RunCMake/try_compile/CompileFlags.cmake
+++ /dev/null
@@ -1,17 +0,0 @@
-enable_language(C)
-set(CMAKE_C_FLAGS_RELEASE "-DPP_ERROR ${CMAKE_C_FLAGS_DEBUG}")
-
-#-
-set(CMAKE_TRY_COMPILE_CONFIGURATION Release)
-try_compile(RESULT ${CMAKE_CURRENT_BINARY_DIR}
-  ${CMAKE_CURRENT_SOURCE_DIR}/src.c
-  OUTPUT_VARIABLE out
-  )
-string(REPLACE "\n" "\n  " out "  ${out}")
-if(RESULT)
-  message(FATAL_ERROR "try_compile passed but should have failed:\n${out}")
-elseif(NOT "x${out}" MATCHES "PP_ERROR is defined")
-  message(FATAL_ERROR "try_compile did not fail with PP_ERROR:\n${out}")
-else()
-  message(STATUS "try_compile with per-config flag worked as expected")
-endif()
diff --git a/Tests/RunCMake/try_compile/RunCMakeTest.cmake 
b/Tests/RunCMake/try_compile/RunCMakeTest.cmake
index ec099fe..4f30f1d 100644
--- a/Tests/RunCMake/try_compile/RunCMakeTest.cmake
+++ b/Tests/RunCMake/try_compile/RunCMakeTest.cmake
@@ -25,7 +25,6 @@ run_cmake(TargetTypeInvalid)
 run_cmake(TargetTypeStatic)
 
 run_cmake(CMP0056)
-run_cmake(CompileFlags)
 
 if(RunCMake_GENERATOR MATCHES "Make|Ninja")
   # Use a single build tree for a few tests without cleaning.
diff --git a/Tests/RunCMake/try_compile/src.c b/Tests/RunCMake/try_compile/src.c
index 5e51382..8488f4e 100644
--- a/Tests/RunCMake/try_compile/src.c
+++ b/Tests/RunCMake/try_compile/src.c
@@ -2,6 +2,3 @@ int main(void)
 {
   return 0;
 }
-#ifdef 

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-586-g29f8f5f

[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  29f8f5f6c24a1f513644c564098ba5be09cd33f0 (commit)
   via  d6409f1f4ed7a4aab1ba7f48c9e2c3aabfffc342 (commit)
  from  c2b11d8dcb21a881e3b8df37bf54aca8c3dad6c8 (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=29f8f5f6c24a1f513644c564098ba5be09cd33f0
commit 29f8f5f6c24a1f513644c564098ba5be09cd33f0
Merge: c2b11d8 d6409f1
Author: Brad King 
AuthorDate: Tue Jun 28 11:33:50 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 11:33:50 2016 -0400

Merge topic 'refactor-auto_ptr' into next

d6409f1f Avoid using KWSys auto_ptr and use std::auto_ptr when possible


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d6409f1f4ed7a4aab1ba7f48c9e2c3aabfffc342
commit d6409f1f4ed7a4aab1ba7f48c9e2c3aabfffc342
Author: Brad King 
AuthorDate: Tue Jun 28 10:17:52 2016 -0400
Commit: Brad King 
CommitDate: Tue Jun 28 11:25:13 2016 -0400

Avoid using KWSys auto_ptr and use std::auto_ptr when possible

Replace use of cmsys::auto_ptr with a CM_AUTO_PTR macro that maps to
std::auto_ptr when possible.  Otherwise, fall back to our own
implementation adopted from the KWSys auto_ptr implementation with
compatibility code removed.

Automate the client site conversions:

git grep -l auto_ptr -- Source/ | grep -v Source/kwsys/ | xargs sed -i \
  's|cmsys::auto_ptr|CM_AUTO_PTR|;s|cmsys/auto_ptr.hxx|cm_auto_ptr.hxx|'

diff --git a/Help/manual/cmake-developer.7.rst 
b/Help/manual/cmake-developer.7.rst
index 7bfdcad..afaccc6 100644
--- a/Help/manual/cmake-developer.7.rst
+++ b/Help/manual/cmake-developer.7.rst
@@ -24,9 +24,10 @@ to build with such toolchains.
 std::auto_ptr
 -
 
-Some implementations have a ``std::auto_ptr`` which can not be used as a
-return value from a function. ``std::auto_ptr`` may not be used. Use
-``cmsys::auto_ptr`` instead.
+The ``std::auto_ptr`` template is deprecated in C++11.  We want to use it
+so we can build on C++98 compilers but we do not want to turn off compiler
+warnings about deprecated interfaces in general.  Use the ``CM_AUTO_PTR``
+macro instead.
 
 size_t
 --
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index fd73984..d49ebbb 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -364,6 +364,7 @@ set(SRCS
   cmake.cxx
   cmake.h
 
+  cm_auto_ptr.hxx
   cm_get_date.h
   cm_get_date.c
   cm_sha2.h
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index b5b364d..97216c3 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -1044,7 +1044,7 @@ std::string 
cmCPackWIXGenerator::CreateNewIdForPath(std::string const& path)
 std::string cmCPackWIXGenerator::CreateHashedId(
   std::string const& path, std::string const& normalizedFilename)
 {
-  cmsys::auto_ptr sha1 = cmCryptoHash::New("SHA1");
+  CM_AUTO_PTR sha1 = cmCryptoHash::New("SHA1");
   std::string hash = sha1->HashString(path.c_str());
 
   std::string identifier;
diff --git a/Source/CPack/cmCPackGenerator.cxx 
b/Source/CPack/cmCPackGenerator.cxx
index 914d0dc..df8bb0f 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -624,7 +624,7 @@ int cmCPackGenerator::InstallProjectViaInstallCMakeProjects(
 cm.AddCMakePaths();
 cm.SetProgressCallback(cmCPackGeneratorProgress, this);
 cmGlobalGenerator gg();
-cmsys::auto_ptr mf(
+CM_AUTO_PTR mf(
   new cmMakefile(, cm.GetCurrentSnapshot()));
 if (!installSubDirectory.empty() && installSubDirectory != "/") {
   tempInstallDirectory += installSubDirectory;
diff --git a/Source/CPack/cpack.cxx b/Source/CPack/cpack.cxx
index b4a2c6f..771519c 100644
--- a/Source/CPack/cpack.cxx
+++ b/Source/CPack/cpack.cxx
@@ -185,7 +185,7 @@ int main(int argc, char const* const* argv)
   cminst.GetCurrentSnapshot().SetDefaultDefinitions();
   cminst.GetState()->RemoveUnscriptableCommands();
   cmGlobalGenerator cmgg();
-  cmsys::auto_ptr globalMF(
+  CM_AUTO_PTR globalMF(
 new cmMakefile(, cminst.GetCurrentSnapshot()));
 #if defined(__CYGWIN__)
   globalMF->AddDefinition("CMAKE_LEGACY_CYGWIN_WIN32", "0");
diff --git a/Source/CTest/cmCTestLaunch.cxx b/Source/CTest/cmCTestLaunch.cxx
index 477f16e..3eed79e 100644
--- a/Source/CTest/cmCTestLaunch.cxx
+++ b/Source/CTest/cmCTestLaunch.cxx
@@ -612,7 +612,7 @@ int cmCTestLaunch::Main(int argc, const char* const argv[])
 

Re: [CMake] [Visual Studio] Is it possible to specify a different target architecture?

[Hendrik Sattler]

Hi,

Yes, it is possible.
Generate the solution for Visual Studio 11 2012 and open it in VS2015. VS will 
ask you once if to convert the project and you say no. Done.

HS


Am 28. Juni 2016 15:51:47 MESZ, schrieb Adam Rankin :
>Hello all,
>
>I am wondering if there exist CMake commands/variables to specify for
>Visual Studio to have the project file(s) generated target a different
>architecture than the one associated with that version of Visual
>Studio.
>
>For example, I develop in VS2015, but would like to target the VS2012
>redistributable (v110).
>
>Is this possible?
>
>Kind regards,
>Adam
>
>
>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] [Visual Studio] Is it possible to specify a different target architecture?

[Greg Marr]

From: CMake > on behalf 
of Adam Rankin >
Date: Tuesday, June 28, 2016 at 9:51 AM
To: "cmake@cmake.org" 
>
Subject: [CMake] [Visual Studio] Is it possible to specify a different target 
architecture?

Hello all,

I am wondering if there exist CMake commands/variables to specify for Visual 
Studio to have the project file(s) generated target a different architecture 
than the one associated with that version of Visual Studio.

For example, I develop in VS2015, but would like to target the VS2012 
redistributable (v110).

Add the command line parameter `-T v110`

https://cmake.org/cmake/help/v3.0/manual/cmake.1.html

-T 

Specify toolset name if supported by generator.

Some CMake generators support a toolset name to be given to the native build 
system to choose a compiler. This is supported only on specific generators:

Visual Studio >= 10
Xcode >= 3.0


See native build system documentation for allowed toolset names.

-- 

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] How do you handle recursive dependencies in CMake

[Raymond Wan]

Hi,


On Tue, Jun 28, 2016 at 8:41 PM, Cfyz  wrote:
> dependencies' locations. Personally I do not agree with that as I see
> neither any way around specifying paths to dependencies not any substantial
> harm in that. Maybe I am missing something but as far as I've found there
> was not discussion about this matter before.


Actually, there has been discussions about transitive dependencies
before.  In fact, such discussions crop up once a month or two.

See for example,
http://public.kitware.com/pipermail/cmake/2016-January/062590.html
(which I did reply, also with a link to my GitHub repository with a
minimal example).  Perhaps many others before me have also done the
same.  [Again, just because I reply doesn't mean I think I'm
right...I'm learning through discussions, as well!]

In my humble opinion, Sven's problem is two-fold.  They are
inter-related, but they could be separated.  The first is the
transitive dependency and for this, if it's all within the same source
code tree then something like what I did could work.  The second is
that the dependencies are not installed in system-level directories,
even though multiple users on a super-computer need to share them.

Because of this second factor, I don't have an idea what Sven should
do.  Indeed, what you suggest could work -- as I don't have a need, I
haven't given that much thought.

I think if I were presented with the same problem as Sven, I'd ask the
system administrator to install it.  Or, if that wasn't possible, use
ExternalProject.  Yes, if there are 100 users, then there would be 100
copies of the dependency.  But, running CMake will grab the most
recent copy from the source repository.  It's inefficient in terms of
disk space, but at least A (assuming A depends on B) will be built
correctly.  I don't know if CMake's aim is to build software correctly
*and* save disk space...  :-)

Ray
-- 

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] [Visual Studio] Is it possible to specify a different target architecture?

[Adam Rankin]

Well now don’t I feel silly…

Thanks!

Adam

From: Benjamin Ballet [mailto:bbal...@ivsweb.com]
Sent: Tuesday, June 28, 2016 9:59 AM
To: Adam Rankin 
Cc: cmake@cmake.org
Subject: Re: [CMake] [Visual Studio] Is it possible to specify a different 
target architecture?

Hi

Look at the 
CMAKE_VS_PLATFORM_TOOLSET
 variable

2016-06-28 15:51 GMT+02:00 Adam Rankin 
>:
Hello all,

I am wondering if there exist CMake commands/variables to specify for Visual 
Studio to have the project file(s) generated target a different architecture 
than the one associated with that version of Visual Studio.

For example, I develop in VS2015, but would like to target the VS2012 
redistributable (v110).

Is this possible?

Kind regards,
Adam

--

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



--
Benjamin BALLET
Ingénieur R

ACTIVISU
19, rue Klock - 92110 Clichy
> Standard Tél :  01 44 69 37 37
> www.activisu.com
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] [Visual Studio] Is it possible to specify a different target architecture?

[Benjamin Ballet via CMake]

Hi

Look at the CMAKE_VS_PLATFORM_TOOLSET

 variable

2016-06-28 15:51 GMT+02:00 Adam Rankin :

> Hello all,
>
>
>
> I am wondering if there exist CMake commands/variables to specify for
> Visual Studio to have the project file(s) generated target a different
> architecture than the one associated with that version of Visual Studio.
>
>
>
> For example, I develop in VS2015, but would like to target the VS2012
> redistributable (v110).
>
>
>
> Is this possible?
>
>
>
> Kind regards,
>
> Adam
>
> --
>
> 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
>



-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] [Visual Studio] Is it possible to specify a different target architecture?

[Adam Rankin]

Hello all,

I am wondering if there exist CMake commands/variables to specify for Visual 
Studio to have the project file(s) generated target a different architecture 
than the one associated with that version of Visual Studio.

For example, I develop in VS2015, but would like to target the VS2012 
redistributable (v110).

Is this possible?

Kind regards,
Adam
-- 

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.6.0-rc3-584-gc2b11d8

[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  c2b11d8dcb21a881e3b8df37bf54aca8c3dad6c8 (commit)
   via  843402b04a72ec1f99f0f712c4eb73abbcb67cba (commit)
  from  db92ed4ef202cabc08e89e30ddf9d5253b196980 (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=c2b11d8dcb21a881e3b8df37bf54aca8c3dad6c8
commit c2b11d8dcb21a881e3b8df37bf54aca8c3dad6c8
Merge: db92ed4 843402b
Author: Brad King 
AuthorDate: Tue Jun 28 09:44:33 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 09:44:33 2016 -0400

Merge topic 'GenerateExportHeader-custom-content' into next

843402b0 GenerateExportHeader: Add option to specify custom content


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=843402b04a72ec1f99f0f712c4eb73abbcb67cba
commit 843402b04a72ec1f99f0f712c4eb73abbcb67cba
Author: Brad King 
AuthorDate: Tue Jun 28 09:42:08 2016 -0400
Commit: Brad King 
CommitDate: Tue Jun 28 09:43:52 2016 -0400

GenerateExportHeader: Add option to specify custom content

diff --git a/Help/release/dev/GenerateExportHeader-custom-content.rst 
b/Help/release/dev/GenerateExportHeader-custom-content.rst
new file mode 100644
index 000..161261c
--- /dev/null
+++ b/Help/release/dev/GenerateExportHeader-custom-content.rst
@@ -0,0 +1,6 @@
+GenerateExportHeader-custom-content
+---
+
+* The :module:`GenerateExportHeader` module learned a new
+  ``CUSTOM_CONTENT_FROM_VARIABLE`` option to specify a variable
+  containing custom content for inclusion in the generated header.
diff --git a/Modules/GenerateExportHeader.cmake 
b/Modules/GenerateExportHeader.cmake
index 6389d30..6205b8c 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -20,6 +20,7 @@
 #  [NO_DEPRECATED_MACRO_NAME ]
 #  [DEFINE_NO_DEPRECATED]
 #  [PREFIX_NAME ]
+#  [CUSTOM_CONTENT_FROM_VARIABLE ]
 #)
 #
 #
@@ -60,8 +61,10 @@
 # The CMake fragment will generate a file in the
 # ``${CMAKE_CURRENT_BINARY_DIR}`` called ``somelib_export.h`` containing the
 # macros ``SOMELIB_EXPORT``, ``SOMELIB_NO_EXPORT``, ``SOMELIB_DEPRECATED``,
-# ``SOMELIB_DEPRECATED_EXPORT`` and ``SOMELIB_DEPRECATED_NO_EXPORT``.  The
-# resulting file should be installed with other headers in the library.
+# ``SOMELIB_DEPRECATED_EXPORT`` and ``SOMELIB_DEPRECATED_NO_EXPORT``.
+# They will be followed by content taken from the variable specified by
+# the ``CUSTOM_CONTENT_FROM_VARIABLE`` option, if any.
+# The resulting file should be installed with other headers in the library.
 #
 # The ``BASE_NAME`` argument can be used to override the file name and the
 # names used for the macros:
@@ -288,7 +291,7 @@ macro(_DO_GENERATE_EXPORT_HEADER TARGET_LIBRARY)
   set(options DEFINE_NO_DEPRECATED)
   set(oneValueArgs PREFIX_NAME BASE_NAME EXPORT_MACRO_NAME EXPORT_FILE_NAME
 DEPRECATED_MACRO_NAME NO_EXPORT_MACRO_NAME STATIC_DEFINE
-NO_DEPRECATED_MACRO_NAME)
+NO_DEPRECATED_MACRO_NAME CUSTOM_CONTENT_FROM_VARIABLE)
   set(multiValueArgs)
 
   cmake_parse_arguments(_GEH "${options}" "${oneValueArgs}" "${multiValueArgs}"
@@ -361,6 +364,14 @@ macro(_DO_GENERATE_EXPORT_HEADER TARGET_LIBRARY)
   endif()
   string(MAKE_C_IDENTIFIER ${EXPORT_IMPORT_CONDITION} EXPORT_IMPORT_CONDITION)
 
+  if(_GEH_CUSTOM_CONTENT_FROM_VARIABLE)
+if(DEFINED "${_GEH_CUSTOM_CONTENT_FROM_VARIABLE}")
+  set(CUSTOM_CONTENT "${${_GEH_CUSTOM_CONTENT_FROM_VARIABLE}}")
+else()
+  set(CUSTOM_CONTENT "")
+endif()
+  endif()
+
   configure_file("${_GENERATE_EXPORT_HEADER_MODULE_DIR}/exportheader.cmake.in"
 "${EXPORT_FILE_NAME}" @ONLY)
 endmacro()
diff --git a/Modules/exportheader.cmake.in b/Modules/exportheader.cmake.in
index 7cfbcbd..9dd75bf 100644
--- a/Modules/exportheader.cmake.in
+++ b/Modules/exportheader.cmake.in
@@ -38,5 +38,5 @@
 #define @NO_DEPRECATED_MACRO_NAME@
 #  endif
 #endif
-
+@CUSTOM_CONTENT@
 #endif
diff --git 
a/Tests/Module/GenerateExportHeader/lib_shared_and_static/CMakeLists.txt 
b/Tests/Module/GenerateExportHeader/lib_shared_and_static/CMakeLists.txt
index c1be125..a057746 100644
--- a/Tests/Module/GenerateExportHeader/lib_shared_and_static/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/lib_shared_and_static/CMakeLists.txt
@@ -25,9 +25,12 @@ add_library(shared_variant SHARED ${lib_SRCS})
 set_target_properties(shared_variant PROPERTIES DEFINE_SYMBOL 
SHARED_VARIANT_MAKEDLL)
 add_library(static_variant ${lib_SRCS})
 
+set(MY_CUSTOM_CONTENT "#define 

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-582-gdb92ed4

[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  db92ed4ef202cabc08e89e30ddf9d5253b196980 (commit)
   via  4bbfea17510d25c950747c4b0f877e5d5b1f528e (commit)
  from  fb2f66b6933a95d22f7ca1df9e9be45b771f3640 (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=db92ed4ef202cabc08e89e30ddf9d5253b196980
commit db92ed4ef202cabc08e89e30ddf9d5253b196980
Merge: fb2f66b 4bbfea1
Author: Brad King 
AuthorDate: Tue Jun 28 09:16:47 2016 -0400
Commit: Brad King 
CommitDate: Tue Jun 28 09:16:47 2016 -0400

Merge branch 'master' into next


---

Summary of changes:


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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc3-275-g4bbfea1

[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  4bbfea17510d25c950747c4b0f877e5d5b1f528e (commit)
   via  c6a077d6980ea164578b7544c852ddf1e8a8a35b (commit)
  from  f91312175822e94d66a92cb919dc04096609a7a7 (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=4bbfea17510d25c950747c4b0f877e5d5b1f528e
commit 4bbfea17510d25c950747c4b0f877e5d5b1f528e
Merge: f913121 c6a077d
Author: Brad King 
AuthorDate: Tue Jun 28 09:16:38 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 09:16:38 2016 -0400

Merge topic 'doc-cross-reference-lang-standard-and-extensions'

c6a077d6 Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162)


---

Summary of changes:
 Help/prop_tgt/CXX_EXTENSIONS.rst |3 ++-
 Help/prop_tgt/CXX_STANDARD.rst   |2 ++
 Help/prop_tgt/C_EXTENSIONS.rst   |3 ++-
 Help/prop_tgt/C_STANDARD.rst |2 ++
 4 files changed, 8 insertions(+), 2 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-580-gfb2f66b

[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  fb2f66b6933a95d22f7ca1df9e9be45b771f3640 (commit)
   via  c6a077d6980ea164578b7544c852ddf1e8a8a35b (commit)
  from  9d1b5b13d3ae39e617b8b14cee52d8f251ea6669 (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=fb2f66b6933a95d22f7ca1df9e9be45b771f3640
commit fb2f66b6933a95d22f7ca1df9e9be45b771f3640
Merge: 9d1b5b1 c6a077d
Author: Brad King 
AuthorDate: Tue Jun 28 09:14:41 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 09:14:41 2016 -0400

Merge topic '16162-cross-reference-doc' into next

c6a077d6 Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c6a077d6980ea164578b7544c852ddf1e8a8a35b
commit c6a077d6980ea164578b7544c852ddf1e8a8a35b
Author: Gregor Jasny 
AuthorDate: Sat Jun 25 14:23:56 2016 +0200
Commit: Brad King 
CommitDate: Tue Jun 28 09:14:00 2016 -0400

Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162)

diff --git a/Help/prop_tgt/CXX_EXTENSIONS.rst b/Help/prop_tgt/CXX_EXTENSIONS.rst
index 0f547e29..280bb3a 100644
--- a/Help/prop_tgt/CXX_EXTENSIONS.rst
+++ b/Help/prop_tgt/CXX_EXTENSIONS.rst
@@ -6,7 +6,8 @@ Boolean specifying whether compiler specific extensions are 
requested.
 This property specifies whether compiler specific extensions should be
 used.  For some compilers, this results in adding a flag such
 as ``-std=gnu++11`` instead of ``-std=c++11`` to the compile line.  This
-property is ``ON`` by default.
+property is ``ON`` by default. The basic C++ standard level is
+controlled by the :prop_tgt:`CXX_STANDARD` target property.
 
 See the :manual:`cmake-compile-features(7)` manual for information on
 compile features and a list of supported compilers.
diff --git a/Help/prop_tgt/CXX_STANDARD.rst b/Help/prop_tgt/CXX_STANDARD.rst
index edc9ba5..5b186c1 100644
--- a/Help/prop_tgt/CXX_STANDARD.rst
+++ b/Help/prop_tgt/CXX_STANDARD.rst
@@ -22,6 +22,8 @@ with a compiler which does not support ``-std=gnu++11`` or an 
equivalent
 flag will not result in an error or warning, but will instead add the
 ``-std=gnu++98`` flag if supported.  This "decay" behavior may be controlled
 with the :prop_tgt:`CXX_STANDARD_REQUIRED` target property.
+Additionally, the :prop_tgt:`CXX_EXTENSIONS` target property may be used to
+control whether compiler-specific extensions are enabled on a per-target basis.
 
 See the :manual:`cmake-compile-features(7)` manual for information on
 compile features and a list of supported compilers.
diff --git a/Help/prop_tgt/C_EXTENSIONS.rst b/Help/prop_tgt/C_EXTENSIONS.rst
index fce67f4..05b14ce 100644
--- a/Help/prop_tgt/C_EXTENSIONS.rst
+++ b/Help/prop_tgt/C_EXTENSIONS.rst
@@ -6,7 +6,8 @@ Boolean specifying whether compiler specific extensions are 
requested.
 This property specifies whether compiler specific extensions should be
 used.  For some compilers, this results in adding a flag such
 as ``-std=gnu11`` instead of ``-std=c11`` to the compile line.  This
-property is ``ON`` by default.
+property is ``ON`` by default. The basic C standard level is
+controlled by the :prop_tgt:`C_STANDARD` target property.
 
 See the :manual:`cmake-compile-features(7)` manual for information on
 compile features and a list of supported compilers.
diff --git a/Help/prop_tgt/C_STANDARD.rst b/Help/prop_tgt/C_STANDARD.rst
index 5e36821..815a686 100644
--- a/Help/prop_tgt/C_STANDARD.rst
+++ b/Help/prop_tgt/C_STANDARD.rst
@@ -22,6 +22,8 @@ with a compiler which does not support ``-std=gnu11`` or an 
equivalent
 flag will not result in an error or warning, but will instead add the
 ``-std=gnu99`` or ``-std=gnu90`` flag if supported.  This "decay" behavior may
 be controlled with the :prop_tgt:`C_STANDARD_REQUIRED` target property.
+Additionally, the :prop_tgt:`C_EXTENSIONS` target property may be used to
+control whether compiler-specific extensions are enabled on a per-target basis.
 
 See the :manual:`cmake-compile-features(7)` manual for information on
 compile features and a list of supported compilers.

---

Summary of changes:


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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-578-g9d1b5b1

[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  9d1b5b13d3ae39e617b8b14cee52d8f251ea6669 (commit)
   via  e8f75bf026daa0fa0a9781ae1140004ea79b2519 (commit)
  from  e7df754963dadf6c40f946f0ed5bd52809e7df2a (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=9d1b5b13d3ae39e617b8b14cee52d8f251ea6669
commit 9d1b5b13d3ae39e617b8b14cee52d8f251ea6669
Merge: e7df754 e8f75bf
Author: Brad King 
AuthorDate: Tue Jun 28 09:13:29 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 09:13:29 2016 -0400

Merge topic '16162-cross-reference-doc' into next

e8f75bf0 fixup! Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS 
(#16162)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8f75bf026daa0fa0a9781ae1140004ea79b2519
commit e8f75bf026daa0fa0a9781ae1140004ea79b2519
Author: Brad King 
AuthorDate: Tue Jun 28 09:10:43 2016 -0400
Commit: Brad King 
CommitDate: Tue Jun 28 09:10:43 2016 -0400

fixup! Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162)

diff --git a/Help/prop_tgt/CXX_STANDARD.rst b/Help/prop_tgt/CXX_STANDARD.rst
index 37c3e5a..5b186c1 100644
--- a/Help/prop_tgt/CXX_STANDARD.rst
+++ b/Help/prop_tgt/CXX_STANDARD.rst
@@ -21,9 +21,9 @@ means that using:
 with a compiler which does not support ``-std=gnu++11`` or an equivalent
 flag will not result in an error or warning, but will instead add the
 ``-std=gnu++98`` flag if supported.  This "decay" behavior may be controlled
-with the :prop_tgt:`CXX_STANDARD_REQUIRED` target property. Eventually 
available
-compiler extensions for the requested standard could be controlled with the
-:prop_tgt:`CXX_EXTENSIONS` target property.
+with the :prop_tgt:`CXX_STANDARD_REQUIRED` target property.
+Additionally, the :prop_tgt:`CXX_EXTENSIONS` target property may be used to
+control whether compiler-specific extensions are enabled on a per-target basis.
 
 See the :manual:`cmake-compile-features(7)` manual for information on
 compile features and a list of supported compilers.
diff --git a/Help/prop_tgt/C_STANDARD.rst b/Help/prop_tgt/C_STANDARD.rst
index 52c4a34..815a686 100644
--- a/Help/prop_tgt/C_STANDARD.rst
+++ b/Help/prop_tgt/C_STANDARD.rst
@@ -22,8 +22,8 @@ with a compiler which does not support ``-std=gnu11`` or an 
equivalent
 flag will not result in an error or warning, but will instead add the
 ``-std=gnu99`` or ``-std=gnu90`` flag if supported.  This "decay" behavior may
 be controlled with the :prop_tgt:`C_STANDARD_REQUIRED` target property.
-Eventually available compiler extensions for the requested standard could be
-controlled with the :prop_tgt:`C_EXTENSIONS` target property.
+Additionally, the :prop_tgt:`C_EXTENSIONS` target property may be used to
+control whether compiler-specific extensions are enabled on a per-target basis.
 
 See the :manual:`cmake-compile-features(7)` manual for information on
 compile features and a list of supported compilers.

---

Summary of changes:
 Help/prop_tgt/CXX_STANDARD.rst |6 +++---
 Help/prop_tgt/C_STANDARD.rst   |4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-576-ge7df754

[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  e7df754963dadf6c40f946f0ed5bd52809e7df2a (commit)
   via  f91312175822e94d66a92cb919dc04096609a7a7 (commit)
   via  f23d846a971b99ec23bee1ff2afaee845a846e5f (commit)
   via  1b021a64f8bf4d9544acb18628e3821f61f49e10 (commit)
   via  7287893d411dde3b9afc6a4c8896dd9d15db9e04 (commit)
  from  98deb55dd1887ae6f7961c128ab875dde22f40b4 (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=e7df754963dadf6c40f946f0ed5bd52809e7df2a
commit e7df754963dadf6c40f946f0ed5bd52809e7df2a
Merge: 98deb55 f913121
Author: Brad King 
AuthorDate: Tue Jun 28 09:06:52 2016 -0400
Commit: Brad King 
CommitDate: Tue Jun 28 09:06:52 2016 -0400

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] How do you handle recursive dependencies in CMake

[Sven Baars]

Hey Cfyz,

After reading your post to the list, it does indeed seem like we have
the same problem. I also wrote a lot of homebrew code you mentioned at
the end of the post, but it indeed always seems to always break
something for some user of the code, even though it seems to work for
everyone else. Hence my question if there is some "right" way of doing
this with CMake, without all of the code I wrote to work around the problem.

In the mean time I'll have a look at the code you wrote, but it seems
very similar to something I already had, which broke for some users.

Sven

On 06/28/2016 02:35 PM, Cfyz wrote:
> Hello.
>
> I've posted a message a few days ago on a very similar subject. Didn't
> know there was a discussion already.
>
> The main problem in my opinion is that CMake target exporting system
> does not handle transitive dependencies at all. CMake handles them
> correctly at the build step, but not at the export. As I've noted in
> my message there is a small hint on that being a conscious decision:
> documentation about target_link_libraries and relevant target
> properties advises not to include paths to dependencies into the
> target interface as it would hard-code dependencies' locations.
> Personally I do not agree with that as I see neither any way around
> specifying paths to dependencies not any substantial harm in that.
> Maybe I am missing something but as far as I've found there was not
> discussion about this matter before.
>
> With that there are some ways to make transitive dependencies work.
> Though you'll have to forsake most of CMake's export machinery.
> Probably the easiest way is to make each library export it's full
> interface in the Foo_INCLUDE_DIRS / Foo_LIBRARIES variables. By
> writing the AConfig.cmake by hand you can figure out and export the
> full path to the A. Therefore AConfig.cmake will essentially be:
>
>   get_filename_component(A_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
>   find_library(A_LIB "A" HINTS ${A_CONFIG_DIR}/../../../lib)
>   set(A_INCLUDE_DIRS ${A_CONFIG_DIR}/../../../include)
>   set(A_LIBRARIES ${A_LIB})
>   set(A_FOUND TRUE)
>
> From here on, every other library which care about its dependencies
> will have to export its interface in a similar way. However, since
> BConfig.cmake cannot find A by itself, it will need some help from the
> project configuration step. B project will need to gather its
> interface and do a configure_file() fixing B's interface dependencies
> in it:
>
>   find_package(A)
>   list(APPEND B_INTERFACE_INCLUDE_DIRS ${A_INCLUDE_DIRS})
>   list(APPEND B_INTERFACE_LIBRARIES ${A_LIBRARIES}) # here comes the
> full path to A library
>   ...
>   configure_file(BConfig.cmake.in 
> ${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/BConfig.cmake @ONLY)
>
> Where BConfig.cmake.in  may look like:
>
>   get_filename_component(B_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
>   find_library(B_LIB "B" HINTS ${B_CONFIG_DIR}/../../../lib)
>   set(B_INCLUDE_DIRS ${B_CONFIG_DIR}/../../../include
> @B_INTERFACE_INCLUDE_DIRS@)
>   set(B_LIBRARIES ${B_LIB} @B_INTERFACE_LIBRARIES@)
>   set(B_FOUND TRUE)
>
> Now find_package(B) will export B_INCLUDE_DIRS / B_LIBRARIES which
> will list full paths to everything necessary to build against it.
>
> At my company we usually use static libraries so that it's rarely a
> problem but with dynamic libraries (.so) this approach will not be
> enough to run the app. Searching for dynamic libraries is not exactly
> the build system responsibility, though and greatly depends on the
> platform and the way you distribute the resulting application. If
> anything it always possible to make another transitive Foo_RPATHS
> property.
>
> This 'simple' approach does not work with libraries that export
> 'imported targets' only (if I recall correctly, the Qt find module
> exports Qt::XYZ targets but not Qt_LIBRARIES) so that there is no
> interface variables to merge. In this case one would need to iterate
> over imported targets and merge their INTERFACE_xxx properties in a
> similar way.
>
> I believe this to be an oversight. Everything should be fine if there
> was an option to resolve and export transitive dependencies along the
> targets in CMake export() command. Probably this may be fixed by an
> external helper script (similar to CMakePackageConfigHelpers module)
> providing some function that takes a list of targets, analyzes them
> and writes a config file complete with targets and their dependencies.
>
> On 28 June 2016 at 13:35, Sven Baars  > wrote:
>
> Hey Ray,
>
> Project A is used by many projects, and so is project B. So
> ExternalProject is not the right solution. I just want to be able
> to fix
> project B in such a way that people, including myself, can easily
> use it
> without knowledge of where project A is located. The packages will all
> be used mostly on 

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc3-266-gf23d846

[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  f23d846a971b99ec23bee1ff2afaee845a846e5f (commit)
   via  234deec2ea265f130a220547bcbc697bacbb25c6 (commit)
   via  963b576fd2605f25ced8790fc17f5baa6ecee761 (commit)
   via  9f2728cef3763dff93a43b933a10f32eb73f7c6b (commit)
   via  149539d9c2d90da76facbd70c969b82af8e2448a (commit)
   via  f30b0fec749710e7eec68ddd148215609a5c01f9 (commit)
  from  1b021a64f8bf4d9544acb18628e3821f61f49e10 (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=f23d846a971b99ec23bee1ff2afaee845a846e5f
commit f23d846a971b99ec23bee1ff2afaee845a846e5f
Merge: 1b021a6 234deec
Author: Brad King 
AuthorDate: Tue Jun 28 09:06:37 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 09:06:37 2016 -0400

Merge topic 'FindHDF5-handle-unsuffixed'

234deec2 FindHDF5: create all the *_LIBRARIES when using hdf5-config.cmake
963b576f FindHDF5: cache the correct path to the high level libraries
9f2728ce FindHDF5: When component targets not found fallback to compiler 
wrappers
149539d9 FindHDF5: Handle HDF5 builds with non-suffixed components
f30b0fec FindHDF5: correctly add lang to each component target name.


---

Summary of changes:
 Modules/FindHDF5.cmake |   25 +
 1 file changed, 21 insertions(+), 4 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.6.0-rc3-273-gf913121

[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  f91312175822e94d66a92cb919dc04096609a7a7 (commit)
   via  059a6ca07a6f8bb4e101e9b269d6bdb4c0281018 (commit)
   via  1d6909a287bb73b5ec7bf51ec56f7efcf2a869eb (commit)
   via  b4b73f56a26c1e1d630e3f262d2d4bafee8231c4 (commit)
   via  a7a92390964ea5aa7021f71ee69fcc71c4229516 (commit)
   via  9e2d6f0c4d19e1ae1652071ea783ad577ea93e28 (commit)
   via  2ca76a6651dd16586334067f6a41524a4015adc9 (commit)
  from  f23d846a971b99ec23bee1ff2afaee845a846e5f (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=f91312175822e94d66a92cb919dc04096609a7a7
commit f91312175822e94d66a92cb919dc04096609a7a7
Merge: f23d846 059a6ca
Author: Brad King 
AuthorDate: Tue Jun 28 09:06:39 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 09:06:39 2016 -0400

Merge topic 'compiler-features'

059a6ca0 Merge branch 'unknown-aliased-target' into compiler-features
1d6909a2 use CM_NULLPTR
b4b73f56 cxx features: add check for nullptr
a7a92390 mark functions with CM_OVERRIDE
9e2d6f0c CM_OVERRIDE: mark destructor overridden in the feature test.
2ca76a66 Validate target name in ALIASED_TARGET property getter


---

Summary of changes:
 Source/CPack/IFW/cmCPackIFWGenerator.cxx   |   16 +-
 Source/CPack/IFW/cmCPackIFWGenerator.h |   29 ++--
 Source/CPack/IFW/cmCPackIFWInstaller.cxx   |4 +-
 Source/CPack/IFW/cmCPackIFWPackage.cxx |8 +-
 Source/CPack/IFW/cmCPackIFWRepository.cxx  |4 +-
 Source/CPack/cmCPack7zGenerator.h  |4 +-
 Source/CPack/cmCPackArchiveGenerator.cxx   |6 +-
 Source/CPack/cmCPackArchiveGenerator.h |   10 +-
 Source/CPack/cmCPackComponentGroup.h   |4 +-
 Source/CPack/cmCPackDebGenerator.cxx   |   10 +-
 Source/CPack/cmCPackDebGenerator.h |   14 +-
 Source/CPack/cmCPackGenerator.cxx  |   22 +--
 Source/CPack/cmCPackGenerator.h|4 +-
 Source/CPack/cmCPackGeneratorFactory.cxx   |4 +-
 Source/CPack/cmCPackGeneratorFactory.h |2 +-
 Source/CPack/cmCPackLog.cxx|8 +-
 Source/CPack/cmCPackLog.h  |2 +-
 Source/CPack/cmCPackNSISGenerator.cxx  |   14 +-
 Source/CPack/cmCPackNSISGenerator.h|   17 +-
 Source/CPack/cmCPackRPMGenerator.cxx   |4 +-
 Source/CPack/cmCPackRPMGenerator.h |   14 +-
 Source/CPack/cmCPackSTGZGenerator.h|   10 +-
 Source/CPack/cmCPackTGZGenerator.h |4 +-
 Source/CPack/cmCPackTXZGenerator.h |4 +-
 Source/CPack/cmCPackTarBZip2Generator.h|4 +-
 Source/CPack/cmCPackTarCompressGenerator.h |4 +-
 Source/CPack/cmCPackZIPGenerator.h |4 +-
 Source/CPack/cpack.cxx |   12 +-
 Source/CTest/cmCTestBZR.cxx|   16 +-
 Source/CTest/cmCTestBZR.h  |   12 +-
 Source/CTest/cmCTestBatchTestHandler.h |4 +-
 Source/CTest/cmCTestBuildAndTestHandler.cxx|   18 +--
 Source/CTest/cmCTestBuildAndTestHandler.h  |   10 +-
 Source/CTest/cmCTestBuildCommand.cxx   |   16 +-
 Source/CTest/cmCTestBuildCommand.h |   12 +-
 Source/CTest/cmCTestBuildHandler.cxx   |   23 +--
 Source/CTest/cmCTestBuildHandler.h |6 +-
 Source/CTest/cmCTestCVS.cxx|5 +-
 Source/CTest/cmCTestCVS.h  |6 +-
 Source/CTest/cmCTestCommand.h  |4 +-
 Source/CTest/cmCTestConfigureCommand.cxx   |   17 +-
 Source/CTest/cmCTestConfigureCommand.h |6 +-
 Source/CTest/cmCTestConfigureHandler.h |4 +-
 Source/CTest/cmCTestCoverageCommand.cxx|2 +-
 Source/CTest/cmCTestCoverageCommand.h  |   10 +-
 Source/CTest/cmCTestCoverageHandler.cxx|   10 +-
 Source/CTest/cmCTestCoverageHandler.h  |6 +-
 Source/CTest/cmCTestCurl.cxx   |2 +-
 Source/CTest/cmCTestEmptyBinaryDirectoryCommand.h  |8 +-
 Source/CTest/cmCTestGIT.cxx|   39 +++--
 Source/CTest/cmCTestGIT.h  |   12 +-
 Source/CTest/cmCTestGenericHandler.cxx |4 +-
 

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc3-260-g1b021a6

[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  1b021a64f8bf4d9544acb18628e3821f61f49e10 (commit)
   via  15b3f6f0f187ab12c29e437f737356bed13d977b (commit)
  from  7287893d411dde3b9afc6a4c8896dd9d15db9e04 (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=1b021a64f8bf4d9544acb18628e3821f61f49e10
commit 1b021a64f8bf4d9544acb18628e3821f61f49e10
Merge: 7287893 15b3f6f
Author: Brad King 
AuthorDate: Tue Jun 28 09:06:34 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 09:06:34 2016 -0400

Merge topic 'ninja-no-rsp-for-rc'

15b3f6f0 ninja, rc: ignore CMAKE_NINJA_FORCE_RESPONSE_FILE for RC files


---

Summary of changes:
 Source/cmNinjaTargetGenerator.cxx   |6 --
 Tests/CMakeLists.txt|3 +++
 Tests/VSResourceNinjaForceRSP/CMakeLists.txt|7 +++
 Tests/{VSResource => VSResourceNinjaForceRSP}/lib.cpp   |0
 .../CompatibleInterface => VSResourceNinjaForceRSP}/main.cpp|3 ++-
 Tests/{VSResource/lib.rc => VSResourceNinjaForceRSP/test.rc}|0
 6 files changed, 16 insertions(+), 3 deletions(-)
 create mode 100644 Tests/VSResourceNinjaForceRSP/CMakeLists.txt
 copy Tests/{VSResource => VSResourceNinjaForceRSP}/lib.cpp (100%)
 copy Tests/{RunCMake/CompatibleInterface => VSResourceNinjaForceRSP}/main.cpp 
(63%)
 copy Tests/{VSResource/lib.rc => VSResourceNinjaForceRSP/test.rc} (100%)


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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc3-568-g5317213

[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  53172138c490efe4e0b446c15af40fce00d09558 (commit)
   via  e593f58b19c63036eacc983d3c8e2c077dab08b5 (commit)
  from  d3f7f4ee06beddd42de105c917906fc732eb9462 (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=53172138c490efe4e0b446c15af40fce00d09558
commit 53172138c490efe4e0b446c15af40fce00d09558
Merge: d3f7f4e e593f58
Author: Brad King 
AuthorDate: Tue Jun 28 09:01:59 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Jun 28 09:01:59 2016 -0400

Merge topic 'compiler-features' into next

e593f58b fixup! use CM_NULLPTR


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e593f58b19c63036eacc983d3c8e2c077dab08b5
commit e593f58b19c63036eacc983d3c8e2c077dab08b5
Author: Brad King 
AuthorDate: Tue Jun 28 09:01:03 2016 -0400
Commit: Brad King 
CommitDate: Tue Jun 28 09:01:44 2016 -0400

fixup! use CM_NULLPTR

diff --git a/Source/cmake.h b/Source/cmake.h
index 007774f..4a5376d 100644
--- a/Source/cmake.h
+++ b/Source/cmake.h
@@ -574,7 +574,7 @@ private:
   F(cxx_long_long_type)   \
   F(cxx_noexcept) \
   F(cxx_nonstatic_member_init)\
-  F(cxx_nullptr)   \
+  F(cxx_nullptr)  \
   F(cxx_override) \
   F(cxx_range_for)\
   F(cxx_raw_string_literals)  \

---

Summary of changes:
 Source/cmake.h |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] How do you handle recursive dependencies in CMake

[Cfyz]

Hello.

I've posted a message a few days ago on a very similar subject. Didn't know
there was a discussion already.

The main problem in my opinion is that CMake target exporting system does
not handle transitive dependencies at all. CMake handles them correctly at
the build step, but not at the export. As I've noted in my message there is
a small hint on that being a conscious decision: documentation about
target_link_libraries and relevant target properties advises not to include
paths to dependencies into the target interface as it would hard-code
dependencies' locations. Personally I do not agree with that as I see
neither any way around specifying paths to dependencies not any substantial
harm in that. Maybe I am missing something but as far as I've found there
was not discussion about this matter before.

With that there are some ways to make transitive dependencies work. Though
you'll have to forsake most of CMake's export machinery. Probably the
easiest way is to make each library export it's full interface in the
Foo_INCLUDE_DIRS / Foo_LIBRARIES variables. By writing the AConfig.cmake by
hand you can figure out and export the full path to the A. Therefore
AConfig.cmake will essentially be:

  get_filename_component(A_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
  find_library(A_LIB "A" HINTS ${A_CONFIG_DIR}/../../../lib)
  set(A_INCLUDE_DIRS ${A_CONFIG_DIR}/../../../include)
  set(A_LIBRARIES ${A_LIB})
  set(A_FOUND TRUE)

>From here on, every other library which care about its dependencies will
have to export its interface in a similar way. However, since BConfig.cmake
cannot find A by itself, it will need some help from the project
configuration step. B project will need to gather its interface and do a
configure_file() fixing B's interface dependencies in it:

  find_package(A)
  list(APPEND B_INTERFACE_INCLUDE_DIRS ${A_INCLUDE_DIRS})
  list(APPEND B_INTERFACE_LIBRARIES ${A_LIBRARIES}) # here comes the full
path to A library
  ...
  configure_file(BConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/BConfig.cmake @ONLY)

Where BConfig.cmake.in may look like:

  get_filename_component(B_CONFIG_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
  find_library(B_LIB "B" HINTS ${B_CONFIG_DIR}/../../../lib)
  set(B_INCLUDE_DIRS ${B_CONFIG_DIR}/../../../include
@B_INTERFACE_INCLUDE_DIRS@)
  set(B_LIBRARIES ${B_LIB} @B_INTERFACE_LIBRARIES@)
  set(B_FOUND TRUE)

Now find_package(B) will export B_INCLUDE_DIRS / B_LIBRARIES which will
list full paths to everything necessary to build against it.

At my company we usually use static libraries so that it's rarely a problem
but with dynamic libraries (.so) this approach will not be enough to run
the app. Searching for dynamic libraries is not exactly the build system
responsibility, though and greatly depends on the platform and the way you
distribute the resulting application. If anything it always possible to
make another transitive Foo_RPATHS property.

This 'simple' approach does not work with libraries that export 'imported
targets' only (if I recall correctly, the Qt find module exports Qt::XYZ
targets but not Qt_LIBRARIES) so that there is no interface variables to
merge. In this case one would need to iterate over imported targets and
merge their INTERFACE_xxx properties in a similar way.

I believe this to be an oversight. Everything should be fine if there was
an option to resolve and export transitive dependencies along the targets
in CMake export() command. Probably this may be fixed by an external helper
script (similar to CMakePackageConfigHelpers module) providing some
function that takes a list of targets, analyzes them and writes a config
file complete with targets and their dependencies.

On 28 June 2016 at 13:35, Sven Baars  wrote:

> Hey Ray,
>
> Project A is used by many projects, and so is project B. So
> ExternalProject is not the right solution. I just want to be able to fix
> project B in such a way that people, including myself, can easily use it
> without knowledge of where project A is located. The packages will all
> be used mostly on supercomputers, where users never have rights to
> install anything, and even if they install them as a module, it is still
> in a non-standard path. As you can see from the example, this works fine
> for project B which depends on A, but not for project C which depends on
> B. Even if you set the PATH correctly.
>
> Sven
>
> On 06/28/2016 12:25 PM, Raymond Wan wrote:
> > Hi Sven,
> >
> >
> > On Tue, Jun 28, 2016 at 6:03 PM, Sven Baars  wrote:
> >> The packages I use are installed in a non-standard path, because I don't
> >> have access to the system directories on most systems I work on, but are
> >> used by many other libraries. They are also all separate packages, not
> >> packages in the same source tree. I did not see my attachment on the
> >> mailing list archive, so instead I just put it on Github. It can be
> >> found here:
> >>
> >> 

[CMake] CMake Windows Visual Studio 14 problems

[Simon Ricaldone]

Hello

Firstly I am very new to CMake, C and Visual Studio so please excuse my 
ignorance!

My problem is I am trying to convert an old Visual Studio 6 project into a 
Visual Studio 14 2015 solution using CMake, however I am having difficulties 
settings compiler flags.  I have been unable to find relevant documentation or 
advice on web on how to achieve the necessary builds steps I need to achieve.  
The build I am trying to achieve is as following;


1.   Use cl.exe to compile source but not link code

2.   Use rc.exe to embed resource file into object code

3.   Use link.exe to link objects into a DLL

The problem I am having is the link stage probably due to an issue with the 
compiler flags I am setting via CMAKE_C_FLAGS, CMAKE_RC_FLAGS and 
CMAKE_LINKER_FLAGS, they appear not to override the default CMAKE settings.

I have attached a copy of my CMakeLists.txt file to see if I am missing the 
obvious!

Thanks in advance
Simon


cmake_minimum_required(VERSION 3.4)

project(example C)

set(SDK_INCLUDE_PATH "C:/Program Files\ (x86)/Microsoft\ 
SDKs/Windows/v7.1A/Include/")
set(WIN32_LIB_PATH "C:/Program Files\ (x86)/Microsoft\ SDKs/Windows/v7.1A/Lib")
set(WIN_32_LIB "WSock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib 
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib 
odbc32.lib odbccp32.lib")

set(includeDir "${CMAKE_SOURCE_DIR}/include/")
set(resourceDir "${CMAKE_SOURCE_DIR}/resources/")

include_directories(
${includeDir}
${SDK_INCLUDE_PATH}
${resourceDir}
)

link_directories(
"${WIN32_LIB_PATH} ${WIN_32_LIB}"
)


set(src example.c "${includeDir}example1.c" example.rc)

set(c_flags "/nologo /c /EHsc /GS- /MTd /Od /TC /Zi /Zp2 /D _USING_V110_SDK71_" 
)
set(CMAKE_C_FLAGS "${c_flags}")

set(rc_flags "/l 0x809")
set(CMAKE_RC_FLAGS "${rc_flags}")

set(linker_flags /NOLOGO /SUBSYSTEM:console /MACHINE:I386 /DLL)
set(CMAKE_LINKER_FLAGS "${linker_flags}")

set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)
set(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)
set(RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)

add_library(cuimbct SHARED ${src})
-- 

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] How do you handle recursive dependencies in CMake

[Sven Baars]

Hey Ray,

Project A is used by many projects, and so is project B. So
ExternalProject is not the right solution. I just want to be able to fix
project B in such a way that people, including myself, can easily use it
without knowledge of where project A is located. The packages will all
be used mostly on supercomputers, where users never have rights to
install anything, and even if they install them as a module, it is still
in a non-standard path. As you can see from the example, this works fine
for project B which depends on A, but not for project C which depends on
B. Even if you set the PATH correctly.

Sven

On 06/28/2016 12:25 PM, Raymond Wan wrote:
> Hi Sven,
>
>
> On Tue, Jun 28, 2016 at 6:03 PM, Sven Baars  wrote:
>> The packages I use are installed in a non-standard path, because I don't
>> have access to the system directories on most systems I work on, but are
>> used by many other libraries. They are also all separate packages, not
>> packages in the same source tree. I did not see my attachment on the
>> mailing list archive, so instead I just put it on Github. It can be
>> found here:
>>
>> https://github.com/Sbte/cmake-example
>>
>> I hope the example shows my workflow, and also what doesn't work for me.
>
> H, in that case, I should probably remain quiet as this is not
> quite something I've had to do.
>
> Maybe the only advice I can give is, if you plan to distribute your
> work to others, what are your expectations in terms of where do you
> think users should install these dependencies.
>
> For example, if it's a system-level directory, then maybe you can
> consider a FIND_PACKAGE solution which has a list of default paths to
> search.  When you're developing on your own computer, you just change
> the default path to include paths in your home directory.
>
> There is also the ExternalProject () directive which you could
> consider [https://cmake.org/cmake/help/v3.3/module/ExternalProject.html]
> .  This would retrieve the dependencies from outside sources (i.e.,
> repositories) and build them.  This would keep everything within the
> same build/ path and I haven't done that (and didn't mention it
> before) because all of my packages are within the same source tree.
>
> So, still not quite your situation, though.
>
> I hope this helps!  Perhaps others can chime in and help you with
> exactly what you're stuck with...
>
> Ray

-- 

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] How do you handle recursive dependencies in CMake

[Raymond Wan]

Hi Sven,


On Tue, Jun 28, 2016 at 6:03 PM, Sven Baars  wrote:
> The packages I use are installed in a non-standard path, because I don't
> have access to the system directories on most systems I work on, but are
> used by many other libraries. They are also all separate packages, not
> packages in the same source tree. I did not see my attachment on the
> mailing list archive, so instead I just put it on Github. It can be
> found here:
>
> https://github.com/Sbte/cmake-example
>
> I hope the example shows my workflow, and also what doesn't work for me.


H, in that case, I should probably remain quiet as this is not
quite something I've had to do.

Maybe the only advice I can give is, if you plan to distribute your
work to others, what are your expectations in terms of where do you
think users should install these dependencies.

For example, if it's a system-level directory, then maybe you can
consider a FIND_PACKAGE solution which has a list of default paths to
search.  When you're developing on your own computer, you just change
the default path to include paths in your home directory.

There is also the ExternalProject () directive which you could
consider [https://cmake.org/cmake/help/v3.3/module/ExternalProject.html]
.  This would retrieve the dependencies from outside sources (i.e.,
repositories) and build them.  This would keep everything within the
same build/ path and I haven't done that (and didn't mention it
before) because all of my packages are within the same source tree.

So, still not quite your situation, though.

I hope this helps!  Perhaps others can chime in and help you with
exactly what you're stuck with...

Ray
-- 

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] How do you handle recursive dependencies in CMake

[Sven Baars]

Hi Ray,

The packages I use are installed in a non-standard path, because I don't
have access to the system directories on most systems I work on, but are
used by many other libraries. They are also all separate packages, not
packages in the same source tree. I did not see my attachment on the
mailing list archive, so instead I just put it on Github. It can be
found here:

https://github.com/Sbte/cmake-example

I hope the example shows my workflow, and also what doesn't work for me.

Sven

On 06/28/2016 11:52 AM, Raymond Wan wrote:
> Hi Sven,
>
>
> On Tue, Jun 28, 2016 at 5:26 PM, Sven Baars  wrote:
>> Hey all,
>>
>> Since I did not receive a reply to my previous mail, I decided to write a
>> minimal example explaining my problem, where I kept al the names as I used
>> in my previous mails. I hope that after seeing my example, someone can
>> explain me what I am doing wrong here. I included a script that reproduces
>> the problem.
>>
>> Cheers,
>> Sven
>
> I'm not much of an expert with CMake, but I can explain to you what
> I've done, at least.
>
> If I understand correctly, package X makes use of package Y, but
> during compilation, it cannot find it?  I think what you can do
> depends on whether X and Y are in two separate source trees.
>
> If they are, then it is almost like Y is the zlib library.  Then what
> you can do is, like the zlib library, install it into a system
> directory (i.e., via INSTALL ()) and then X will use a FIND_PACKAGE to
> look for it.
>
> But, suppose Y isn't like zlib.  For example, it is a library that is
> within the same source tree and will only ever be used by X (both of
> which are written by you).  I think this is the scenario that you're
> talking about?  In my case, I have done this in my CMakeLists.txt:
>
> SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
>
> I guess you can set it
> [https://cmake.org/cmake/help/v3.3/variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY.html]
> to anything so that all of the libraries will be installed into one
> place without doing an INSTALL.  Of course, this directory is or
> somewhere within the build/ directory.  (I suppose doing an install
> into ${CMAKE_BINARY_DIR} would achieve the same thing?)
>
> I had previously installed Y's archive into a system directory, but
> besides the need to run FIND_PACKAGE, I thought it was "silly" to
> install an archive into a system directory that is only used by my own
> program.  Seems a bit messy and intrusive to the end-user -- my
> libraries are quite unlike zlib; few chance someone else will use it
> :-) .  At the very least, this approach keeps it in one place within
> build/ .
>
> I'm not sure if it is the "right" way to do it, but this is what I do
> at the moment...  I hope it helps!
>
> Ray

-- 

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] How do you handle recursive dependencies in CMake

[Raymond Wan]

Hi Sven,


On Tue, Jun 28, 2016 at 5:26 PM, Sven Baars  wrote:
> Hey all,
>
> Since I did not receive a reply to my previous mail, I decided to write a
> minimal example explaining my problem, where I kept al the names as I used
> in my previous mails. I hope that after seeing my example, someone can
> explain me what I am doing wrong here. I included a script that reproduces
> the problem.
>
> Cheers,
> Sven


I'm not much of an expert with CMake, but I can explain to you what
I've done, at least.

If I understand correctly, package X makes use of package Y, but
during compilation, it cannot find it?  I think what you can do
depends on whether X and Y are in two separate source trees.

If they are, then it is almost like Y is the zlib library.  Then what
you can do is, like the zlib library, install it into a system
directory (i.e., via INSTALL ()) and then X will use a FIND_PACKAGE to
look for it.

But, suppose Y isn't like zlib.  For example, it is a library that is
within the same source tree and will only ever be used by X (both of
which are written by you).  I think this is the scenario that you're
talking about?  In my case, I have done this in my CMakeLists.txt:

SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})

I guess you can set it
[https://cmake.org/cmake/help/v3.3/variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY.html]
to anything so that all of the libraries will be installed into one
place without doing an INSTALL.  Of course, this directory is or
somewhere within the build/ directory.  (I suppose doing an install
into ${CMAKE_BINARY_DIR} would achieve the same thing?)

I had previously installed Y's archive into a system directory, but
besides the need to run FIND_PACKAGE, I thought it was "silly" to
install an archive into a system directory that is only used by my own
program.  Seems a bit messy and intrusive to the end-user -- my
libraries are quite unlike zlib; few chance someone else will use it
:-) .  At the very least, this approach keeps it in one place within
build/ .

I'm not sure if it is the "right" way to do it, but this is what I do
at the moment...  I hope it helps!

Ray
-- 

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] How do you handle recursive dependencies in CMake

[Sven Baars]

Hey all,

Since I did not receive a reply to my previous mail, I decided to write
a minimal example explaining my problem, where I kept al the names as I
used in my previous mails. I hope that after seeing my example, someone
can explain me what I am doing wrong here. I included a script that
reproduces the problem.

Cheers,
Sven

On 06/10/2016 01:34 PM, Sven Baars wrote:
> Hey Chuck,
>
> In ATargets.cmake it says
>
> add_library(a SHARED IMPORTED)
>
> and in BTargets.cmake it says
>
> add_library(b SHARED IMPORTED)
>
> However, if I build C it will say
>
> /usr/bin/ld: cannot find -la
>
> when I do
>
> find_package(B)
> target_link_libraries(c b)
> add_executable(main main.cpp)
> target_link_libraries(main c)
>
> This, I think, because the 'b' target depends on 'a' but doesn't know
> where 'a' is located, because this is not described in BTargets.cmake.
>
> Sven
>
> On 06/08/2016 06:07 PM, Chuck Atkins wrote:
>> If the projects are each providing their own Config.cmake file then
>> you probably will want to use those instead of Find modules.  Instead
>> of using the Foo_Bar_LIBRARIES variable though, try using the actual
>> imported targets from the config files.  Those should have the
>> appropriate dependency information. If you're not sure what they are
>> you should be able to dig through the provided Config.cmake and
>> Targets.cmake files for FooBar and see which targets are created bu
>> "add_library(FooBar::Foo ... IMPORTED)".
>>
>> - Chuck
>>
>> On Wed, Jun 8, 2016 at 11:31 AM, Sven Baars > > wrote:
>>
>> In my case all projects provide their own FooBarConfig.cmake, but
>> not a FindFooBar.cmake. For this reason I wanted to use those,
>> because I thought it saves me the effort of writing a lot of
>> FindFooBar.cmake files, and it also seemed like the right way to
>> do it, because it provides things like FooBar_LIBRARIES, which is
>> what I need. The reason I said that I create my own
>> FooBarConfig.cmake, is because I want to use CMake properly in my
>> own project, so I also want to provide a FoorBarConfig.cmake file
>> for my users. So even if the projects I use don't do everything
>> properly, I still want to do it properly myself. The problem in
>> this case is that I'm not sure what the proper way is. If the
>> FoorBarConfig.cmake file is not enough to handle the dependencies
>> I encounter, should I provide a FindFooBar.cmake file or
>> something, instead of just the FooBarConfig.cmake? And meanwhile
>> also write a FindFooBar.cmake file for all my dependencies?
>>
>> Another reason why this seems odd to me, is because if N
>> different projects use FooBar, then also possibly N different
>> versions of FindFooBar.cmake are created by all the different
>> projects (I have actually already seen this a lot). That is the
>> case, because the FindFooBar.cmake file is not provided by the
>> FooBar project, unlike the FooBarConfig.cmake.
>>
>> Cheers,
>> Sven
>>
>>
>> On 06/08/2016 03:11 PM, Chuck Atkins wrote:
>>> The FooBarConfig.cmake is something that should be generated by
>>> FooBar's build.   The reason you don't get absolute paths for
>>> the "libraries" from a package config file is that they're not
>>> actually libraries but imported targets.  The imported target
>>> let's you treat "foo" as though it were a library built by your
>>> project.  It then has the appropriate target properties set on
>>> it ti define the full path to it's library, etc.  That being
>>> said, if you're manually creating the FooBarConfig.cmake that's
>>> not really the right approach.  If the FooBar buil;d doesn't
>>> actually generate it's own FooBarConfig.cmake file then you'll
>>> want to create you're own FindFooBar.cmake.  A bare bones find
>>> module that creates an imported target would look something like
>>> this:
>>>
>>> if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar)
>>>   find_path(FooBar_INCLUDE_DIR FooBar.h)
>>>   find_library(FooBar_LIBRARY FooBar)
>>>
>>>   include(FindPackageHandleStandardArgs)
>>>   find_package_handle_standard_args(FooBar
>>> FOUND_VAR FooBar_FOUND
>>> REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY
>>>   )
>>> endif()
>>>
>>> if(FooBar_FOUND AND NOT TARGET FooBar::FooBar)
>>>   add_library(FooBar::FooBar UNKNOWN IMPORTED)
>>>   set_target_properties(FooBar::FooBar PROPERTIES
>>> IMPORTED_LOCATION ${FooBar_LIBRARY}
>>> INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR}
>>>   )
>>> endif()
>>>
>>> Then in your project you can use:
>>>
>>> find_package(FooBar)
>>> add_library(MyLib supercoolfiles.cxx)
>>> target_libkLibraries(MyLib FooBar::FooBar)
>>>
>>> Where this starts to get really helpful in your situation is if
>>> you have an imported target for A, B, and C, 

Re: [cmake-developers] daemon-mode meeting last Tuesday

[Tobias Hunger]

Hi Brad,
Am 27.06.2016 7:18 nachm. schrieb "Brad King" :
> I will take care of making libuv available within CMake's implementation
> prior to merging the server mode work.  See the "libuv in cmake" branch
> of this thread.

Perfect.

Sorry, I only noticed the other thread after sending my mail.

Best regards,
Tobias
-- 

Powered by www.kitware.com

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

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

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

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

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