Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This is by design.</p> <p>When building a static library, any dependencies to that library will not get linked into the library directly. Instead when building an executable all library dependencies (direct and indirect) will be linked directly to that executable.</p> <p>This is also the way most compiler handle static libraries. While VS does offer a special option to link dependencies into static libs, this is not possible on e.g. gcc without resorting to dirty file hacks. Since CMake only supports features that can be used on all supported generators, CMake will not allow to do this even on VS builds.</p> <p>You have a couple of options now:</p> <ul> <li>Use a dll instead of a static library (<code>add_library(${libname} SHARED ...)</code>). While a static library is basically a bunch of object files wrapped together, a dll is more or less the same as an executable. In particular, all static library dependencies get linked directly into the dll. The disadvantage here is that you have to deal with the usual dll mess: You have to specify which functions to export and the usual issues with passing stuff across dll boundaries apply.</li> <li>Have your find script also search for all the dependencies. You should be able to restructure your library's dependency handling in a way that the amount of code duplication is minimal. The disadvantage is that configuring a third-party application becomes more difficult (especially on Windows) since you now not only need to find the library itself, but also all of its dependencies.</li> <li>Use <a href="http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets" rel="noreferrer">exported targets</a>. This approach makes most sense if the library is built on the same machine as the final executable. Upon building the library, CMake auto-generates the config files for using that library. Your application then just needs to find an include that script and you're good to go. Disadvantage is that the export mechanism is not the most straight-forward feature of CMake, so you will have to spend some time to familiarize yourself with it.</li> <li>Pull in the library sources directly into each executable. Basically each executable does an <code>add_subdirectory</code> on the library source dir. You still have to configure the dependencies for each executable and on top of that you also have to build the library seperately for each executable. You probably don't want to do this.</li> </ul>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COOne option you haven't listed here, will it work if I just distribute the dependencies with the library? As long as they're in the same location as MyLib.lib cmake should be able to find it. It'd mean that clients could do their own links into either a DLL or a fully portable executable. Is this solution likely to cause any unforseen issues? My main concern is that I don't want clients to have to be using the same version of boost for their apps as I used to build the library.
      singulars
    2. CO@OcularProgrammer This is basically option #2: You write a find script that resolves the dependencies, potentially by taking them from your distribution. Mixing library versions is an issue, but unfortunately one that applies to all forms of binary library distribution. If you expose a Boost type on the interface, your library and the executable must both use the same boost version. Otherwise passing boost types across library boundaries will probably mess things up. Contained use of different versions is usually okay, but you should still strive to avoid it if possible.
      singulars
    3. COCheers for the advice. The MyLibConfig.cmake needed a bit of hacking to correctly grab both the library and dependencies from the directory structure, but we now have a nice, portable install package when I grab all the dependencies and move them into the appropriate lib directories. Thank you very much.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload