Possible regression related to INTERFACE_INCLUDE_DIRECTORIES in 2.29.1

Hello! :wave:

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 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:

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


  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

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:

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. :blush:

This is most likely due to the PACKAGE_PREFIX_DIR change that was added in 3.29.1 to fix a bug, but was then reverted 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.

1 Like


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.

You were right. Updating to 3.29.2 resolved this issue.