[CMake] Redundant linking when modifying shared libraries

2019-02-14 Thread Itay Chamiel
Hi, I've asked this question on Stack Overflow almost a year ago with no useful responses (with the same topic if you wish to search for it), so I'm trying my luck here. I work on a large commercial C++ project comprised of a couple dozen dynamically linked shared libraries, each of which has

Re: [CMake] Redundant linking when modifying shared libraries

2019-02-14 Thread Craig Scott
On Thu, Feb 14, 2019 at 9:24 PM Itay Chamiel wrote: > Hi, > > I've asked this question on Stack Overflow almost a year ago with no > useful responses (with the same topic if you wish to search for it), so I'm > trying my luck here. > > I work on a large commercial C++ project comprised of a

Re: [CMake] Redundant linking when modifying shared libraries

2019-02-14 Thread Itay Chamiel
On 2/14/19 12:38 PM, Craig Scott wrote: I think you might be looking for the LINK_DEPENDS_NO_SHARED target property (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED variable).

Re: [CMake] Multiple occurrences of a library on linux (ldd)

2019-02-14 Thread Thompson, KT via CMake
Thiago, I haven’t see the double entry pattern that you mention below. However, you might want to tell CMake to embed a BUILD_RPATH in your libraries. This should get around the issue of manually setting LD_LIBRARY_PATH.

Re: [CMake] Multiple occurrences of a library on linux (ldd)

2019-02-14 Thread Thiago Crepaldi
Thanks, Thompson, I will look into BUILD_RPATH and possibly INSTALL_RPATH. I just learned about `export LD_DEBUG=files` to debug linking issues on linux. It provides more detail on the ldd output, as below: 18843: file=libc10.so [0]; needed by

Re: [CMake] Multiple occurrences of a library on linux (ldd)

2019-02-14 Thread Thiago Crepaldi
I might be getting close and the root cause might be related to a conceptual question that I was saving for later: how transitive linking should be done! Returning to the build design: pytorch is compile if not installed in the system, lib datareader_core consumes pytorch and standalone_gtests

Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?

2019-02-14 Thread Eric Noulard
Le jeu. 14 févr. 2019 à 18:57, Timothy Wrona a écrit : > The problem is it is very likely that there are some circular dependencies > in the build tree -- which is why it was broken up to generation of all, > then build all, then link all in the first place. > Yes, wrong solution to a real

Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?

2019-02-14 Thread Timothy Wrona
I guess what I would ultimately like to achieve would be a "pre-cmake-configuration" step that just initializes the package registry with the location of each project's build tree and copies the "project-config.cmake" files into each projects build-tree. This would allow it to be found during

Re: [CMake] Redundant linking when modifying shared libraries

2019-02-14 Thread Itay Chamiel
On Thu, Feb 14, 2019 at 8:08 PM Robert Maynard wrote: > By default CMake wants to get a correct build 100% of the time. There > is nothing to stop people from having functions defined in a .cxx file > with no corresponding header, and using manual forward deceleration is > used in a consuming

[CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?

2019-02-14 Thread Timothy Wrona
I have a collection of interdependent CMake projects (lots of legacy code) that I want to convert to using CMake targets for linking. The code is built in such a way that all projects run cmake generation, then all projects build, then all projects link. I would like to export a CMake target from

Re: [CMake] Redundant linking when modifying shared libraries

2019-02-14 Thread Itay Chamiel
On Thu, Feb 14, 2019 at 12:39 PM Craig Scott wrote: > I think you might be looking for the LINK_DEPENDS_NO_SHARED target property > (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED variable). After my previous response I experimented a little more, and I got it to work. My mistake

Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?

2019-02-14 Thread Eric Noulard
Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona a écrit : > I have a collection of interdependent CMake projects (lots of legacy code) > that I want to convert to using CMake targets for linking. The code is > built in such a way that all projects run cmake generation, then all > projects build,

Re: [CMake] Redundant linking when modifying shared libraries

2019-02-14 Thread Robert Maynard via CMake
> I wonder why this isn't the default behavior By default CMake wants to get a correct build 100% of the time. There is nothing to stop people from having functions defined in a .cxx file with no corresponding header, and using manual forward deceleration is used in a consuming

Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?

2019-02-14 Thread Timothy Wrona
The problem is it is very likely that there are some circular dependencies in the build tree -- which is why it was broken up to generation of all, then build all, then link all in the first place. With circular dependencies there's no real way to sort these dependencies out without just running

Re: [CMake] Redundant linking when modifying shared libraries

2019-02-14 Thread Robert Maynard via CMake
I agree that we should document this property better. I recommend looking at the CMake wiki ( https://gitlab.kitware.com/cmake/community/wikis/home ) and thinking maybe adding a new recipe for `optimizing redundant linking`. On Thu, Feb 14, 2019 at 3:11 PM Itay Chamiel wrote: > > On Thu, Feb 14,

Re: [CMake] Redundant linking when modifying shared libraries

2019-02-14 Thread Itay Chamiel
Sounds good. The FAQ has a question "Is there a way to skip checking of dependent libraries when compiling?" - perhaps you can add one just before that, something like "Is there a way to reduce the amount of linking when building a large project?".or similar. Thanks again, itay On Thu, Feb 14,

[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-110-ga2a903f

2019-02-14 Thread Kitware Robot via Cmake-commits
t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 8330dc8..e69ceb9 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 14) -set(CMake_VERSION_PATCH 20190214) +set(CMake_VER

Re: [cmake-developers] Properly Documenting a CMake Module

2019-02-14 Thread Gregor Jasny via cmake-developers
Hello, On 14.02.19 04:39, Timothy Wrona wrote: Okay so I dug a little deeper into this and it definitely looks like sphinx is the correct tool to use, but I still have one problem. I would like sphinx to be able to extract ".rst" formatted comments directly out of my cmake source files to

Re: [cmake-developers] Properly Documenting a CMake Module

2019-02-14 Thread Torsten
> Am 14.02.2019 um 14:53 schrieb Timothy Wrona : > > How does Sphinx know to go parse that ".cmake" file? Does Sphinx recognize > the „cmake-module" keyword in a special way and know what to do with it? it’s from a Sphinx module that you can find the in the CMake sources

Re: [cmake-developers] Properly Documenting a CMake Module

2019-02-14 Thread Timothy Wrona
That's what I was looking for! Thanks!!! On Thu, Feb 14, 2019 at 9:04 AM wrote: > > > > Am 14.02.2019 um 14:53 schrieb Timothy Wrona : > > > > How does Sphinx know to go parse that ".cmake" file? Does Sphinx > recognize the „cmake-module" keyword in a special way and know what to do > with it?

Re: [cmake-developers] Properly Documenting a CMake Module

2019-02-14 Thread Timothy Wrona
Hi Gregor, It looks like there's still a little bit of magic here. All those "Help/.rst" files just have a single line in them that says: .. cmake-module:: ../../Modules/.cmake How does Sphinx know to go parse that ".cmake" file? Does Sphinx recognize the "cmake-module" keyword in a special way

[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-100-g0069825

2019-02-14 Thread Kitware Robot via Cmake-commits
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 0069825f50c83b8144374150dd682d48c84f6874 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-96-g50ba2f0

2019-02-14 Thread Kitware Robot via Cmake-commits
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 50ba2f019baa3e5487a975cb72059f1fc178f9d0 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-89-g49a53ca

2019-02-14 Thread Kitware Robot via Cmake-commits
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 49a53cac87fe3a303a2794ccdd7c1b5cecd2d016 (commit) via

[cmake-developers] cuda_compile_ptx re-runs CMake at build time

2019-02-14 Thread Charles Huet
Hi, I'm having an issue with CUDA (sadly the old-style FindCUDA, not the new native support of CUDA). The following CMake file reproduces the issue easily on Windows with any Visual Studio Generator (14 2015 Win64 being the one I use). Adding the file generated by cuda_compile_ptx to any target

[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-104-ge3353a0

2019-02-14 Thread Kitware Robot via Cmake-commits
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 e3353a0175fb27bc2967c3df78b8be1c0615b21d (commit) via

[Cmake-commits] CMake branch, release, updated. v3.14.0-rc1-29-g2f51f28

2019-02-14 Thread Kitware Robot via Cmake-commits
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, release has been updated via 2f51f281a8c9684c25cf97499a4382e1b5ae68b9 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-109-g8c4de81

2019-02-14 Thread Kitware Robot via Cmake-commits
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 8c4de819449bbb1710b1cc2440357757e5cb757c (commit) via