When installing marble to a non-standard system directory
the executable loader needs to be informed about the location of the
marble libraries. Until now for marble executables this needs to be done
via the env var LD_LIBRARY_PATH, which has the disadvantage of needing
to be done as explicit separate step and also affects other executables
which see this env var.
Instead the custom locations of linked libraries can be tagged within
the executable, via the RPATH (or RUNPATH) entries, which then is
automatically available and also only valid for the given executable.

Libmarblewidget only works with data & plugins in installation folders.
So when running executables from the build dir (apps, tools, tests)
linked to libraries from the build dir, for one things might not work
due to not yet installed data/plugins. Or there are API/ABI-related
changes done but without reinstallation, so installed plugins and
libraries in the build dir are incompatible and will fail with
strange behaviour.
To protect against that some more when linking the executables
in the build dir the RPATH can be set already to the installation
location only, so the versions of the libraries in the build dir
will not be seen and at least libraries and plugins are consistent.

More info e.g. here:
https://cmake.org/Wiki/CMake_RPATH_handling
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html