================
@@ -82,7 +87,7 @@ else()
# In-tree configuration
set( LIBCLC_STANDALONE_BUILD FALSE )
- set( LLVM_PACKAGE_VERSION ${LLVM_VERSION} )
+ set( PACKAGE_VERSION ${LLVM_PACKAGE_VERSION} )
----------------
wenju-he wrote:
> I'm a little confused what `in-tree` means here. If it's in the context like
> we're doing here with a runtimes build it should be set.
sorry, you're right that `LLVM_PACKAGE_VERSION` is set in in-tree build when
libclc is in `LLVM_ENABLE_RUNTIMES`.
It is just that our downstream still uses `LLVM_ENABLE_PROJECTS="...,libclc"`
and in this case `LLVM_ENABLE_RUNTIMES` is not set. The reasons of not
switching to `LLVM_ENABLE_RUNTIMES` yet are:
* prepare_builtins has build fail when libclc is in LLVM_ENABLE_RUNTIMES on
windows when MSVC generator is used, see
https://github.com/google/clspv/pull/1521#issuecomment-3287406308 and analysis
at https://github.com/google/clspv/pull/1521#issuecomment-3350179501.
CMAKE_C_COMPILER set at
https://github.com/llvm/llvm-project/blob/80b62cb9b979bf560ea17c127b1e85749376a6a2/llvm/cmake/modules/LLVMExternalProjectUtils.cmake#L228
doesn't work. This could be an blocking issue for switching libclc to
`add_library`.
* `LLVM_ENABLE_RUNTIMES="libclc"` build is much slower than
`LLVM_ENABLE_PROJECTS="libclc"` in debug build when compiling a execution-time
support library which depends on libclc. I have a local workaround for this
issue and long term solution might be removing the dependency on libclc.
https://github.com/llvm/llvm-project/pull/174022
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
