jhuber6 wrote: > That said, I don't believe it "works" in the way it's supposed to. It still > grabs the host tools using `get_host_tool_path` in CMake, and custom commands > to build with that. I take it we're supposed to use `CMAKE_C_COMPILER` as if > we were a regular CMake project? Are we able to use `opt` and `llvm-link` and > other LLVM tools?
Yes, the whole point is that we can use `add_library` instead of custom commands. You can still find those tools and use them if necessary however. For that you'd want to emit an object library and then add a custom command that uses all the generated objects to link / opt them and finally output them. OpenMP's GPU runtime used to do that but I hacked around it with LTO stuff. > I've been using this command to test: > > ``` > cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_ASSERTIONS=ON > -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_ENABLE_RUNTIMES="libclc" > -DLIBCLC_TARGETS_TO_BUILD=amdgcn--amdhsa -DCMAKE_BUILD_TYPE=Release > ``` Yeah, something like `LIBCLC_TARGETS_TO_BUILD` is likely what should be implied by the `LLVM_DEFAULT_TARGET_TRIPLE` value that the runtimes build passes in. (Also, does amdgcn-amd-amdhsa not work? That's the canonical one). > One question you might be able to answer: how can I treat the runtimes build > more like a "regular" build? For instance `ninja -v` doesn't forward `-v` > onto the build so I can't inspect what's happening while building libclc. I > also can't build specific libclc targets such as `ninja > prepare-amdgcn--amdhsa.bc`. It's an external project, it uses the same handling. You can do `ninja -C ./runtimes/runtimes-<triple>-bins` and it will behave the same. https://github.com/llvm/llvm-project/pull/141574 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
