frasercrmck wrote: > 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. https://github.com/llvm/llvm-project/pull/86965 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
