# Possible regression related to INTERFACE\_INCLUDE\_DIRECTORIES in 2.29.1

**URL:** <https://discourse.cmake.org/t/possible-regression-related-to-interface-include-directories-in-2-29-1/10705>\
**Category:** Code\
**Tags:** os:linux\
**Created:** [April 20, 2024, 10:43pm UTC](https://discourse.cmake.org/t/possible-regression-related-to-interface-include-directories-in-2-29-1/10705 "2024-04-20T22:43:13Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mschwaig](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mschwaig/32/4515_2.png) [@mschwaig](https://discourse.cmake.org/u/mschwaig)\
**Post date:** [April 20, 2024, 10:43pm UTC](https://discourse.cmake.org/t/possible-regression-related-to-interface-include-directories-in-2-29-1/10705/1 "2024-04-20T22:43:13Z")

</div>

Hello! 👋

I am on of the maintainers of ROCm for the Nix package manager and NixOS Linux distribution.

We have this big monorepo for all of our packages at [GitHub - NixOS/nixpkgs: Nix Packages collection & NixOS](https://github.com/NixOS/nixpkgs) and do all of our package builds in a sandbox.  
If there are any dependencies between packages, we have to resolve them through absolute paths, which include a hash value, so that we know exactly what we depend on.  
We run CMake and other build systems inside that sandbox.

Recently our build of AMD’s ROCm broke and I was able to use `git bisect` to find out that the commit which updates CMake from 3.29.0 to 3.29.1 introduced this breakage.

From that point forward our builds for a lot of ROCm components fail with error messages like the following:

```auto
CMake Error in CMakeLists.txt:
  Imported target "hip::device" includes non-existent path

    "/include"

  in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.

```

Now I have to admit that I am really not an experienced CMake user, but as far as I understand builds should not break with a version upgrade, if `cmake_minimum_required(VERSION [version number her])` stays the same.

I’m really not confident in what I’m saying here, but I have a feeling one part of the problem might be that ROCm wants distros to set `CMAKE_INSTALL_<dir>`, which is a problem for us because we need to use absolute paths for things like that. We had some workarounds for that, and those might be broken in CMake 3.29.1.

I have opened an issue for this on our end with some more info and links:

> <https://github.com/NixOS/nixpkgs/issues/305641>
>
> \### Steps To Reproduce
> 
> The build for a lot of ROCm components broke with 6083…fb0a158607ce76c1cc0849e89eb35d66cfa7, which updated CMake from 3.29.0 to 3.29.1, basically breaking all of ROCm.
> This commit was merged via https://github.com/NixOS/nixpkgs/pull/298979 and recently made its way from staging into unstable in the last few days.
> 
> Steps to reproduce the behavior:
> 1. \`nix build nixpkgs/716b484faececc3cd4570cc612ec9e927427d682#rocmPackages.rccl\`
> 
> \### Build log
> 
> The builds for a number of ROCm components now fail with error messages like the following:
> 
> \`\`\`
> CMake Error in library/CMakeLists.txt:
> Imported target "hip::device" includes non-existent path
> 
> "/include"
> 
> in its INTERFACE\_INCLUDE\_DIRECTORIES. Possible reasons include:
> 
> \* The path was deleted, renamed, or moved to another location.
> 
> \* An install or uninstall procedure did not complete successfully.
> 
> \* The installation package was faulty and references files it does not
> provide.
> \`\`\`
> 
> \### Additional context
> 
> This is possible related to how ROCm uses \`CMAKE\_INSTALL\_\<dir\>\` of CMake incorrectly.
> See https://github.com/NixOS/nixpkgs/pull/197838#discussion\_r1006537286 and https://github.com/ROCm/rocm-cmake/issues/121 which is linked in that comment thread.
> 
> \### Notify maintainers
> 
> \<!--
> Please @ people who are in the \`meta.maintainers\` list of the offending package or module.
> If in doubt, check \`git blame\` for whoever last touched something.
> \--\>
> 
> \### Metadata
> 
> Please run \`nix-shell -p nix-info --run "nix-info -m"\` and paste the result.
> 
> \`\`\`console
> \[user@system:~\]$ nix-shell -p nix-info --run "nix-info -m"
> output here
> \`\`\`
> 
> \---
> 
> Add a :+1: \[reaction\] to \[issues you find important\].
> 
> \[reaction\]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
> \[issues you find important\]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Is the build breaking like that considered a bug in CMake?  
Should I file an issue for that?  
If you happen to have a better idea for how we could deal with that `CMAKE_INSTALL_<dir>` issue, I’m all ears as well. 😊

---

<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:** [April 20, 2024, 10:52pm UTC](https://discourse.cmake.org/t/possible-regression-related-to-interface-include-directories-in-2-29-1/10705/2 "2024-04-20T22:52:35Z")

</div>

This is most likely due to the [`PACKAGE_PREFIX_DIR` change](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9390) that was added in 3.29.1 to fix a bug, but was then [reverted](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9420) in 3.29.2 due to it breaking a number of projects which were relying on the undocumented variable. Please update to CMake 3.29.2.

---

<div class="post-metadata">

**Author:** ![mschwaig](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mschwaig/32/4515_2.png) [@mschwaig](https://discourse.cmake.org/u/mschwaig)\
**Post date:** [April 20, 2024, 10:59pm UTC](https://discourse.cmake.org/t/possible-regression-related-to-interface-include-directories-in-2-29-1/10705/3 "2024-04-20T22:59:05Z")

</div>

Thanks!

I guess I should have have read the release notes more carefully.

I am trying to build with 3.29.2 now and will post the results here.

---

<div class="post-metadata">

**Author:** ![mschwaig](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mschwaig/32/4515_2.png) [@mschwaig](https://discourse.cmake.org/u/mschwaig)\
**Post date:** [April 21, 2024, 12:03am UTC](https://discourse.cmake.org/t/possible-regression-related-to-interface-include-directories-in-2-29-1/10705/4 "2024-04-21T00:03:51Z")

</div>

You were right. Updating to 3.29.2 resolved this issue.