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
"/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:
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.
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.
