Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

On Wed, 11 May 2016 21:58:34 +1000 Craig Scott wrote: [..] > If you were paying careful attention, you would have noticed that > when A links in B as PRIVATE, the include directories of B never > propagate to something linking to A, but if A is a static library, > then

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

On Thu, 12 May 2016 09:20:10 -0500 iosif neitzke wrote: > I'm sorry, I'm not sure I understand. In your example, there is > target_link_libraries(lib3 PUBLIC lib1). It looks like lib2 has > target_link_libraries(lib2 PRIVATE lib1). Yes. That is correct. When

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

On Thu, 12 May 2016 09:04:10 -0500 iosif neitzke wrote: > target_include_directories(lib1 INTERFACE /tmp) means /tmp is > propagated with lib1, but not used to build lib1. I know. Could you elaborate how this is related with lib3 PRIVATEly linking to lib1?

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

I guess the key is static libraries don't exactly adhere to the rules of PUBLIC or PRIVATE, so you end up with a library that CMake passes along with a populated INTERFACE_INCLUDE_DIRECTORIES, and so exe1 uses it because it is there? Not sure how it is supposed to work at this point. On Thu, May

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

target_include_directories(lib1 INTERFACE /tmp) means /tmp is propagated with lib1, but not used to build lib1. "The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the following arguments. PRIVATE and PUBLIC items will populate the INCLUDE_DIRECTORIES property of .

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

My reading of your examples: exe1 gets linked to lib2, and lib2/bin is included. exe1 probably won't link ultimately because lib2 may need symbols from lib1. Depends on the structure of the C code between lib2 and lib1. See John Lakos for further information on that. exe2 gets linked to lib3,

[CMake] Time Profile our CMake codes

Is there a way to "time profile" our cmake codes? We have noticed lately that running cmake on our project lately has taken a large uptick in time and we are trying to figure out where the newly added time is coming from. We do a lot of I/O writing temp files, comparing temp files to files

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

I'm sorry, I'm not sure I understand. In your example, there is target_link_libraries(lib3 PUBLIC lib1). It looks like lib2 has target_link_libraries(lib2 PRIVATE lib1). http://public.kitware.com/pipermail/cmake/2016-May/063382.html On Thu, May 12, 2016 at 9:10 AM, Patrick Boettcher

Re: [CMake] AUTOMOC with files on different folders

Thanks Attila, really appreciate your help. On Wed, May 11, 2016 at 11:23 PM, Attila Krasznahorkay < attila.krasznahor...@gmail.com> wrote: > Hi Tiago, > > Indeed, that page is quite a bit misleading. And it seems to be "liked" by > Google a lot, as most people come across it. (I also found it

Re: [CMake] Time Profile our CMake codes

We do the File IO because we need to store lists of various directories for other subprojects and packaging schemes to use. When we first developed the CMake codes the "set_property" function was not really well developed. I am wondering if using global property lists are a better way to go

Re: [CMake] AUTOMOC with files on different folders

Hi Tiago, Indeed, that page is quite a bit misleading. And it seems to be "liked" by Google a lot, as most people come across it. (I also found it myself when looking for CMake documentation early on.) In general, listing all source files belonging to a library/executable, even the ones that

Re: [CMake] CPack and PackageMaker

I think it is ok for the most of the use cases. But what I miss are the signing options: e.g: productbuild --component "FULLPATH_TO_OUTPUTDIR" /Applications --sign "DEVELOPER_CERTIFICATE" --product ".../Info.plist" MyPackage.pkg Best regards Roman > Am 05.04.2016 um 03:12 schrieb

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

Patrick, I suggest if you can reduce your problem down to a small, reproducible example, then file a bug. I did a test just now with CMake 3.5.2 and everything behaved as expected, including the header search path propagation, so maybe there's something unusual in your project which a simple case

[CMake] Debug vs Release "install" area

Looking for some advice. In order to make our Visual Studio debugging environment, as self-contained (and easy to use for the developers) as possible, we use developers must run an install. We also use the resulting release based Install for our packaging into our installer. We change the

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

On 05/12/2016 09:34 AM, Rolf Eike Beer wrote: > find_library(${_prefix}-${CMAKE_MATCH_1} > NAMES ${CMAKE_MATCH_1} > ${_find_opts}) > list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}") Generally I try to store the CMAKE_MATCH_ values in other variables as soon as

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

On 05/11/2016 05:52 PM, Rolf Eike Beer wrote: > It has always nagged me that the FindPkgConfig module requires people to use > link_directories(). Now I created a new optional mode for pkg_check_modules() > and pkg_search_modules() which will search the absolute paths of the > libraries > that

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

Am 2016-05-12 14:59, schrieb Brad King: On 05/11/2016 05:52 PM, Rolf Eike Beer wrote: It has always nagged me that the FindPkgConfig module requires people to use link_directories(). Now I created a new optional mode for pkg_check_modules() and pkg_search_modules() which will search the

[Cmake-commits] CMake branch, master, updated. v3.5.2-644-g7057864

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 7057864560f2b54617a1ff603eede13d2730b65b (commit) via

[Cmake-commits] CMake branch, master, updated. v3.5.2-646-gcb704c0

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 cb704c08710bdf6a4ca13261a059c277df26214a (commit) via

[Cmake-commits] CMake branch, master, updated. v3.5.2-642-g4cc32ad

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 4cc32ad538bbb9169e31f275658d40542a56a0bd (commit) via

[Cmake-commits] CMake branch, next, updated. v3.5.2-1346-g085676f

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 085676f2a188ac700d15ccc1b502446ecb039374 (commit) via

Re: [cmake-developers] Using CMake generated ninja file as a subninja file

On 05/12/2016 06:16 AM, Nicolas Desprès wrote: > Brad has just sent a notification email about an upcoming feature freeze. > Do you think we could have this feature merged before? I'll take a look. Please rebase on 'master' to resolve conflicts and also reconcile with the

[cmake-developers] [ANNOUNCE] CMake C++ coding style transition

Hi Folks, As discussed previously on the developer list: Code style auto-formatting http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=15001

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

Am Donnerstag, 12. Mai 2016, 09:53:06 schrieb Brad King: > On 05/12/2016 09:34 AM, Rolf Eike Beer wrote: > > find_library(${_prefix}-${CMAKE_MATCH_1} > > > > NAMES ${CMAKE_MATCH_1} > > ${_find_opts}) > > > > list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}") > >

[Cmake-commits] CMake branch, next, updated. v3.5.2-1357-gaf395dc

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 af395dc4c1196c6665c66ca690d656589c5d873a (commit) via

[Cmake-commits] CMake branch, next, updated. v3.5.2-1355-gab5baf8

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 ab5baf898f59db8e558782e7056f881449015e34 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.5.2-1359-g969ac90

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 969ac90d3805db87e32929de3305d1af5470aba6 (commit) via

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

On 05/12/2016 12:48 PM, Rolf Eike Beer wrote: > Good point. I have changed this accordingly and pushed it to next. There are > no tests yet, so maybe not immediately merge it to next but wait for the > weekend or so. Okay, thanks. Please also add a Help/release/dev/FindPkgConfig-targets.rst

Re: [cmake-developers] Using CMake generated ninja file as a subninja file

On Thu, May 12, 2016 at 3:16 PM, Brad King wrote: > On 05/12/2016 06:16 AM, Nicolas Desprès wrote: > > Brad has just sent a notification email about an upcoming feature freeze. > > Do you think we could have this feature merged before? > > I'll take a look. Please rebase

[cmake-developers] [CMake 0016101]: ADD_SUBDIRECTORY with EXCLUDE_FROM_ALL fails to include target dependencies(XCode Generator)

The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=16101 == Reported By:Robert Bielik Assigned To:

[Cmake-commits] CMake branch, next, updated. v3.5.2-1361-ge358f06

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 e358f069ec4a5d142ee2c8a877c65922201d649c (commit) via

[Cmake-commits] CMake branch, next, updated. v3.5.2-1363-g7da4731

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 7da47311b867e7d8af86766dcfff9124d8c816ca (commit) via

[Cmake-commits] CMake branch, next, updated. v3.5.2-1365-g756e369

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 756e36915134388b0aeaac7548c2a7426d26a56b (commit) via

Re: [cmake-developers] [PATCH] FindBoost does not detect absence of header file

On 11/05/2016 19:43, rle...@codelibre.net wrote: On 2016-05-11 19:30, Chuck Atkins wrote: I guess it doesn't really matter but for the libraries that don't have a single include header, should you be using these instead: * container/container_fwd.hpp * exception/all.hpp *

Re: [cmake-developers] Using CMake generated ninja file as a subninja file

On 05/12/2016 02:16 PM, Nicolas Desprès wrote: > All done. Thank you for taking a look. > https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix The RunCMake.NinjaOutputPathPrefix test fails for me when I have the CMake source and build trees in a directory with a space in the

[Cmake-commits] CMake branch, master, updated. v3.5.2-647-gbdc84a9

_VERSION_MINOR 5) -set(CMake_VERSION_PATCH 20160512) +set(CMake_VERSION_PATCH 20160513) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [cmake-developers] [ANNOUNCE] CMake C++ coding style transition

On Thu, May 12, 2016 at 7:58 AM, Brad King wrote: > Hi Folks, > > As discussed previously on the developer list: > > Code style auto-formatting > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969 > >

Re: [cmake-developers] Using CMake generated ninja file as a subninja file

Hi Ben, Brad has just sent a notification email about an upcoming feature freeze. Do you think we could have this feature merged before? Regards, Nicolas On Sun, Mar 20, 2016 at 1:47 PM, Nicolas Desprès wrote: > > > On Wed, Mar 9, 2016 at 9:41 PM, Ben Boeckel