Hardcoded /lib/cmake path breaks on /lib64 systems

[bwarden]

Clear Linux, a 64-bit distribution, uses /usr/lib64 for libraries and /usr/lib64/cmake for corresponding cmake helpers in. Hard-coding /lib/cmake breaks builds in this environment, and in any others that reserve /usr/lib for 32-bit fallback libraries.

clspv/lib/CMakeLists.txt

Lines 142 to 148 in 55000a5

	if(${EXTERNAL_LLVM} EQUAL 1)
	include(${CLSPV_LLVM_BINARY_DIR}/lib/cmake/llvm/LLVMConfig.cmake)
	llvm_map_components_to_libnames(CLSPV_LLVM_LINKS ${CLSPV_LLVM_COMPONENTS})
	include(${CLSPV_LLVM_BINARY_DIR}/lib/cmake/clang/ClangConfig.cmake)
	endif()

clspv/tools/clspv-opt/CMakeLists.txt

Lines 47 to 50 in 55000a5

	if(${EXTERNAL_LLVM} EQUAL 1)
	include(${CLSPV_LLVM_BINARY_DIR}/lib/cmake/llvm/LLVMConfig.cmake)
	llvm_map_components_to_libnames(CLSPV_LLVM_LINKS ${CLSPV_LLVM_COMPONENTS})
	endif()

[rjodinchr]

I guess one answer would be that this has been made to use an externally built LLVM, meaning not the one from clspv's dependencies. But not to use a LLVM installed somewhere. At least that's what I get looking at the code, and the commits leading to it.
When one builds LLVM (without installing it), those .cmake files are always stored at those paths with lib.

But improving it to support both an externally built LLVM, or an externally installed LLVM would be good.

Note that clspv is not based on a release version of LLVM, as it tries to follow upstream as closely as possible (considering the time available to the maintainers). So using a LLVM installed is not something most people have been looking for, as it's quite rare to align well with clspv needs.