Enable CPack

[ThijsWithaar]

The current build scripts require root access, since LLVM's SPIRV is installed during the build.
This PR enables CPACK, and allows everything to build without root access.

Having packages instead of an install-during-build, helps me keeping my system clean.

Is this something that's acceptable as a change?

[illuhad]

Thank you.

The current build scripts require root access, since LLVM's SPIRV is installed during the build.
This PR enables CPACK, and allows everything to build without root access.

I'm not a cmake expert, but this confuses me. Can you elaborate on your use case? It is already possible to install as a non-privileged user as long as the install directory does not require root permissions. Is this e.g. to allow creating a package that would install to system directories as an unprivileged user?

[ThijsWithaar]

It is already possible to install as a non-privileged user as long as the install directory does not require root permissions

When I'm compiling with the clang as installed by debian, the build script tries to generate files in the clang installation folder. This folder requires root access to write.
So indeed, I'm trying to build a .deb package, but it's the building process that for me requires root access.

As far as I can see, it is the default behaviour of ExternalProject_Add() to perform and install command of that project during the build step of the main archive.

I'm not a cmake expert either, so this is my best attempt at addressing that, but I could imagine this is not the way you'd want to go.

[illuhad]

When I'm compiling with the clang as installed by debian, the build script tries to generate files in the clang installation folder. This folder requires root access to write.

This is not the default behavior. It only tries to write to CMAKE_INSTALL_PREFIX. Are you trying to install into the system-wide clang directory (if so, why?) ?

[ThijsWithaar]

Are you trying to install into the system-wide clang directory (if so, why?) ?

The build-script I'm using is pasted below, which made me realiase that I upgraded clang,
and therefore also used LLVMSPIRV_BRANCH=main.
Could that explain the trying-to-install-to-/usr behaviour?

#!/bin/bash

CLANG_VERSION=18

export CC=/usr/bin/clang-${CLANG_VERSION}
export CXX=/usr/bin/clang++-${CLANG_VERSION}

BUILD_DEPENDENCIES_DEBIAN="libboost-context-dev libboost-fiber-dev clang-${CLANG_VERSION} libclang-${CLANG_VERSION}-dev libomp-${CLANG_VERSION}-dev spirv-tools libze-dev"
dpkg --verify ${BUILD_DEPENDENCIES_DEBIAN} &> /dev/null
if [ $? -ne "0" ]; then
	sudo apt --no-upgrade -y install ${BUILD_DEPENDENCIES_DEBIAN}
fi

if [ ! -d build ]; then
	cmake -GNinja -Bbuild -S. -DCMAKE_BUILD_TYPE=Release -DCPACK_GENERATOR=DEB \
		-DWITH_LEVEL_ZERO_BACKEND=ON -DWITH_ACCELERATED_CPU=ON -DWITH_ROCM_BACKEND=OFF -DWITH_CUDA_BACKEND=OFF -DWITH_SSCP_COMPILER=ON \
		-DLLVMSPIRV_BRANCH=main
fi

cmake --build build -- package

[illuhad]

No, the reason it tries to install to /usr is because you have not set CMAKE_INSTALL_PREFIX to your desired install location, so it just defaults to a system-wide installation in /usr.

PS: We do not recommend using unreleased clang versions, as they tend to have stability issues.

[ThijsWithaar]

No, the reason it tries to install to /usr is because you have not set CMAKE_INSTALL_PREFIX to your desired install location, so it just defaults to a system-wide installation in /usr.

CMAKE_INSTALL_PREFIX also affects the package that CPACK builds, so I was attempting to build both packages with proper install paths in one go.

It seems that that really doesn't fit the existing workflow very well. I made this PR to see if my changes would be helpful for the project as well. It looks like that's not the case, so feel free to close this PR if you think it's too far off from being a helpful addition.

[illuhad]

Is this still needed? Does PR #1172 resolve this issue?