# What controls CPack staging location
**URL:** https://discourse.cmake.org/t/what-controls-cpack-staging-location/1492
**Category:** Usage
**Created:** [July 6, 2020, 4:23pm UTC](https://discourse.cmake.org/t/what-controls-cpack-staging-location/1492 "2020-07-06T16:23:46Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@briadam](https://discourse.cmake.org/u/briadam)
#### Post date: [July 6, 2020, 4:23pm UTC](https://discourse.cmake.org/t/what-controls-cpack-staging-location/1492/1 "2020-07-06T16:23:47Z")
**Background:** Our [Dakota project](http://dakota.sandia.gov) integrates [Trilinos](https://github.com/trilinos/Trilinos) which uses the TriBITS system for CMake builds. (For better or worse) Dakota manages Trilinos as a sub-package with add\_subdirectory. In updating Dakota from Trilinos `d2fcc2f` to `e9cb59b`, we can no longer `make package`.
**My CMake-focused question is:** What might cause CPack to attempt to stage or make install the binary project into ${CMAKE\_INSTALL\_PREFIX} instead of a staging area in the build tree as I’m used to? This behavior is causing a fatal error due to default install prefix in /usr/local. We realize this forum can’t solve our odd integration problem, but are just looking for suggestions as to CMake or CPack variables or other settings we might review in our Dakota/Trilinos integration.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [July 6, 2020, 4:46pm UTC](https://discourse.cmake.org/t/what-controls-cpack-staging-location/1492/2 "2020-07-06T16:46:24Z")
CPack uses `DESTDIR` to “relocate” the installation prior to packaging. There’s no way to control it, but I suspect something is using `${CMAKE_INSTALL_PREFIX}` without `$ENV{DESTDIR}` considerations in the diff between the commits mentioned.
---
### Author:  [@briadam](https://discourse.cmake.org/u/briadam)
#### Post date: [July 6, 2020, 5:45pm UTC](https://discourse.cmake.org/t/what-controls-cpack-staging-location/1492/3 "2020-07-06T17:45:37Z")
Okay thanks @ben.boeckel; I’ll follow that lead a bit. One surprising thing is that with the Trilinos sub-project update, not just Trilinos targets, but **all** installed files, even at the parent (Dakota) level are attempting to install into /usr/local at make package time, so some cache variable must be getting set/unset or otherwise modified. I’m also pursuing this with Trilinos: [https://github.com/trilinos/Trilinos/issues/7636](https://github.com/trilinos/Trilinos/issues/7636)
---
### Author:  [@briadam](https://discourse.cmake.org/u/briadam)
#### Post date: [July 6, 2020, 8:30pm UTC](https://discourse.cmake.org/t/what-controls-cpack-staging-location/1492/4 "2020-07-06T20:30:05Z")
Thanks again for the tip @ben.boeckel. Given inspiration to dig deeper, I read about CPACK\_SET\_DESTDIR, which did change the observed behavior and CPACK\_PACKAGING\_INSTALL\_PREFIX. Those helped me pinpoint the issue.
I was able to track this down to the sub-project overriding CMAKE\_INSTALL\_PREFIX in a custom INSTALL(SCRIPT …). I think this overwrite during the middle of actual install was getting in the way of DESTDIR or other assumptions about the prefix being set or not. Hence all other sub-projects which followed Trilinos in the install chain were breaking. (To be fair, TriBITS / Trilinos is not intended for use as Dakota does, where other sub-projects follow the final install rules in the TriBITS system.)