Setting the RPATH correctly can be rather tricky, but it is essential for third-party users. By default, CMake sets the RPATH of executables assuming they will be run from the build tree. However, upon installation, the RPATH is cleared, leading to trouble when a user would like to run hello-world_wDSO. Using the ldd tool on Linux, we can inspect the hello-world_wDSO executable in the build tree to see where the loader will look for libmessage.so:

libmessage.so.1 => /home/user/cmake-cookbook/chapter-10/recipe-01/cxx-example/build/lib64/libmessage.so.1 (0x00007f7a92e44000)

Running ldd hello-world_wDSO in the installation prefix would result instead in the following:

    libmessage.so.1 => Not found

This is clearly wrong. However, it would be equally wrong to always hardcode the RPATH to point to the build tree or to the installation prefix: any of the two locations could be erased resulting in corrupted executables. The solution presented here sets the RPATH differently for the executable in the build tree and in the installation prefix, so that it will always point to where "it makes sense"; that is, as close to the executable as possible. Running ldd in the build tree shows the same output:

libmessage.so.1 => /home/roberto/Workspace/robertodr/cmake-cookbook/chapter-10/recipe-01/cxx-example/build/lib64/libmessage.so.1 (0x00007f7a92e44000)

On the other hand, in the installation prefix, we now get the following:

libmessage.so.1 => /home/roberto/Software/ch10r01/bin/../lib64/libmessage.so.1 (0x00007fbd2a725000)

We have used the CMake install command with the TARGETS signature, since we needed to install build targets. The command has, however, four additional signatures:

• The FILES and PROGRAMS signatures. These are used to install files or programs, respectively. Upon installation, files will be copied and permissions for them set appropriately. That is, for files, read and write permissions to the owner, read permissions to the group and other users and groups. For programs, execution permissions will be additionally granted. Note that the PROGRAMS signature is meant for use with executables that are not build targets. See also: https://cmake.org/cmake/help/v3.6/command/install.html#installing-files.
• The DIRECTORY signature. As the name suggests, this is used to install directories. When only a directory name is given, it is, as usual, understood to be relative to the current source directory. Granular control over installation of directories is possible. Please consult the online documentation: https://cmake.org/cmake/help/v3.6/command/install.html#installing-directories.
• The SCRIPT signature. You can use this one to define custom installation rules within a CMake script. See https://cmake.org/cmake/help/v3.6/command/install.html#custom-installation-logic.
• The EXPORT signature. We defer discussion of this signature to Recipe 3, Exporting your targets.