[CMake] Redundant linking when modifying shared libraries

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 man

Re: [CMake] Redundant linking when modifying shared libraries

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 coupl

Re: [CMake] Redundant linking when modifying shared libraries

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)

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. https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html?highlight=

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

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 /home/dev/miniconda3/datareaders_py37/build/stage/da

Re: [CMake] Redundant linking when modifying shared libraries

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 was

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

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] Is there a way to delay "find_package" until link-time when the package is actually needed?

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

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

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 g

Re: [CMake] Redundant linking when modifying shared libraries

> 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 library/executable.

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

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 desig

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

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 gener

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

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 con

Re: [CMake] Redundant linking when modifying shared libraries

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 libr

Re: [CMake] Redundant linking when modifying shared libraries

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

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