# How to not install header-sets of private dependencies?

**URL:** https://discourse.cmake.org/t/how-to-not-install-header-sets-of-private-dependencies/11259
**Category:** Code
**Created:** [July 16, 2024, 10:25am UTC](https://discourse.cmake.org/t/how-to-not-install-header-sets-of-private-dependencies/11259 "2024-07-16T10:25:57Z")
**Posts on this page:** 1
**Showing post:** 6

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [July 18, 2024, 11:02pm UTC](https://discourse.cmake.org/t/how-to-not-install-header-sets-of-private-dependencies/11259/6 "2024-07-18T23:02:14Z")

</div>

> [@pboettch](#):
>
> I was facing another problem later on: indirect linking with dependent dynamic libraries when RUNPATH is used (and not RPATH). One needs to add manually `-Wl,--disable-new-dtags` to make modern linkers use RPATH and thus the loader will not clear the paths when loading indirect dependencies.

I just posted [this reply](https://discourse.cmake.org/t/let-shared-lib-load-other-lib-from-relative-path/11276/3) in another thread. RPATH should not be preferred over RUNPATH. The latter is actually more correct, but it exposes insufficiently specified dependencies, which I think you’re trying to do deliberately to work around the “I don’t want to install the headers” problem. If you’re using a superbuild, that really complicates things from an install perspective. Frankly, it’s pretty fragile to try to install things that have been provided to your main build using ExternalProject. It also doesn’t play nice with package managers, if people building your project may want to do that (I don’t know if that’s relevant to your scenario).

---

_[View the full topic](https://discourse.cmake.org/t/how-to-not-install-header-sets-of-private-dependencies/11259)._