[libclc] Track dependencies through dependency files

[frasercrmck]

This commit fixes the problem of missing build dependencies between libclc source files and their various includes (namely headers and .inc files).

We would like to do this with compiler-generated dependency files because then the dependencies are accurate and there are no false positives, leading to unnecessary rebuilds. This is how regular C/C++ dependencies are usually tracked by CMake.

Note that this variable is an internal API so is not guaranteed to work, but then again all of CMake's support for new languages (which we use for CLC/LL languages) is an internal API. On balance this change is probably worth it due to how minimally invasive it is. It should work with all supported compilers and CMake generators.

[arsenm]

The build here seems to be trying to define clc as a language, which then results in needing to rely on language support magic like this. I think it would be better if this did what rocm-device-libs does and treat these as custom targets. I don't think it's particularly helpful to pretend like this is a normal host compiler detection situation.

https://github.com/ROCm/llvm-project/blob/efc7219da809b6bce7b1c92c1915a0eac68fb1f2/amd/device-libs/cmake/OCL.cmake#L136

[arsenm]

In the context of what the build is already doing, this should be fine

[frasercrmck]

The build here seems to be trying to define clc as a language, which then results in needing to rely on language support magic like this. I think it would be better if this did what rocm-device-libs does and treat these as custom targets. I don't think it's particularly helpful to pretend like this is a normal host compiler detection situation.

https://github.com/ROCm/llvm-project/blob/efc7219da809b6bce7b1c92c1915a0eac68fb1f2/amd/device-libs/cmake/OCL.cmake#L136

Yes, I agree. It also makes building libclc in-tree a nuisance, because CMake needs to know the path to the "language compilers" at configure time, which leads to fun like intuiting the final output path of clang and other tools and writing an empty string to those paths to ensure they exist on disk before you call enable_language.

So I agree that moving to custom targets would be beneficial for many reasons. I think overall it would be a simpler solution, not least because it's the more idiomatic way of doing CMake. I might look into that in the near future, but can't promise it.