Fix absolute install DESTINATION that breaks the vcpkg build under CMake >= 4

[mahmoudimus]

TL;DR

src/libtriton/CMakeLists.txt passes an absolute path to install(DESTINATION). That has always been wrong, but it was harmless until CMake 4 turned it into a hard error. The vcpkg workflow installs CMake with lukka/get-cmake@latest, so the runner silently moved from 3.x to 4.4.2 and every PR since has been red.

If you try to reproduce this on CMake 3.x you will not see it. I could not — 3.31.6 accepts the absolute path even with -Werror=dev. That is the main thing to know before reviewing.

Why it only manifests on CMake >= 4

Three things have to line up:

1. install(FILES ... DESTINATION ${CMAKE_INSTALL_PREFIX}/${PYTHON_SITE_PACKAGES}) produces an absolute destination.
2. CMakePresets.json sets "errors": { "dev": true }, so developer warnings are errors.
3. CMake 4 moved install-absolute-destination into the developer-warning category. On 3.x it is not in that category, so errors.dev never applied to it.

Only (3) changed, and it changed on the runner rather than in the repository:

Download action repository 'lukka/get-cmake@latest'
CMake path: '.../cmake-4.4.2-linux-x86_64/bin/'

Timeline, from the workflow's own history:

Date	Head	Result
2026-06-27	dev-v1.0 @ 59f86fa2	last green
2026-08-12	patch-1	red — install-absolute-destination at CMakeLists.txt:378
2026-08-30	this stack	red — same error, line shifted by the commits above it

No commit in between touched this code.

Reproducing in 30 seconds

$ python -m venv /tmp/cm && /tmp/cm/bin/pip install "cmake==4.4.2"
$ /tmp/cm/bin/cmake -B /tmp/b -G Ninja -Werror=dev \
    -DBUILD_SHARED_LIBS=ON -DPYTHON_BINDINGS=ON \
    -DCMAKE_INSTALL_PREFIX=/tmp/prefix .
CMake Error (install-absolute-destination) at src/libtriton/CMakeLists.txt:378 (install):
  INSTALL command given absolute DESTINATION path:
    /tmp/prefix/lib/python3.13/site-packages

Swap cmake==4.4.2 for cmake==3.31.6 and it configures cleanly. That is the whole bug.

The fix

The prefix was redundant to begin with. In this branch PYTHON_SITE_PACKAGES is already relative — the execute_process immediately above prints lib/pythonX.Y/site-packages — and install() resolves a relative DESTINATION against CMAKE_INSTALL_PREFIX. Prefixing it again only made the path absolute.

-install(FILES ... DESTINATION ${CMAKE_INSTALL_PREFIX}/${PYTHON_SITE_PACKAGES})
+install(FILES ... DESTINATION ${PYTHON_SITE_PACKAGES})

Two benefits beyond unbreaking CI: the destination is unchanged for a normal install, and cmake --install --prefix <other> starts working again — an absolute DESTINATION silently ignores it.

The other branch of the if() is deliberately untouched. It installs into the interpreter's real site-packages when no prefix was given, so its absolute path is intended, and it is unreachable from the presets, which always set one.

Verification

With CMake 4.4.2, configuring the way the preset does:

• before — the error above, CMake Generate step failed.
• after — configure and generate clean.
• the generated cmake_install.cmake records ${CMAKE_INSTALL_PREFIX}/lib/python3.13/site-packages — the same location, now resolved against the prefix.
• full build + cmake --install puts the module at <prefix>/lib/python3.13/site-packages/triton.so; it imports and solves a constraint.

Suggestion, separate from this PR

Pinning lukka/get-cmake to an explicit version would stop a toolchain bump on the runner from breaking the build again with no commit to point at. Worth doing regardless of whether this lands, since the same class of surprise will recur with CMake 5.

[mahmoudimus]

Before / after on the same runners

Since the runs on this PR are held pending approval, here is the same workflow on my fork — same .github/workflows/vcpkg.yml, same GitHub-hosted runners, same unpinned get-cmake pulling CMake 4.4.2. The only variable is this commit.

	Head	ubuntu	macOS	Windows
before	pre-fix branch, 2026-08-27	fail	fail	fail
after	d5353b0 (this PR)	pass	pass	pass

• before — run 33124730698: CMake Error (install-absolute-destination) at src/libtriton/CMakeLists.txt:385 (install)
• after — run 33331798262: all three green

So the failure and the fix are both reproducible outside this repository, on stock runners, with no approval needed to look at them.