webkit2gtk

Current: pkgver=2.50.6, pkgrel=8. Published, matches upstream (nvchecker OK).

2026-07-24: fixed the WebKitMacros.cmake / cmake>=4 configure failure

Root cause found and fixed. extra/cmake in our chroot (and in official Arch extra) moved to 4.4.0 on 2026-07-21, which is what made this reproduce locally for the first time – it wasn’t reporter-specific after all.

The bug is in upstream WebKit’s Source/cmake/WebKitMacros.cmake, macro _WEBKIT_TARGET_LINK_FRAMEWORK:

if ((NOT _linked_into) OR (${framework} STREQUAL ${_linked_into}) OR (NOT ${_linked_into} IN_LIST ${_target}_FRAMEWORKS))

${_linked_into} (the <framework>_LINKED_INTO GLOBAL PROPERTY) is genuinely empty the first time this runs: LLIntSettingsExtractor (a bootstrap executable JavaScriptCore builds to generate offlineasm headers) links WTF before JavaScriptCore’s own WEBKIT_FRAMEWORK(JavaScriptCore) call ever sets WTF’s _LINKED_INTO property – a real ordering/bootstrap situation, not a one-off. An unquoted empty variable inside if() vanishes as a token instead of becoming an empty-string argument, so this produces a malformed argument list ("WTF" "STREQUAL" with nothing after, "NOT" "IN_LIST" "..." with nothing before). Something changed in cmake 4.x’s if() argument validation and it started rejecting that malformed list outright (“Unknown arguments specified”) instead of tolerating it. Checked WebKit upstream main on GitHub: still unquoted as of 2026-07-24, so no upstream fix to pull in yet. Checked official Arch webkit2gtk-4.1 PKGBUILD too: no patch there either – it just hasn’t been rebuilt since cmake 4.4.0 landed (last build 2026-07-14), so this is likely a brewing problem for them too, not something already solved elsewhere.

Fix: quote both variables so the comparisons stay well-formed when empty – ("${framework}" STREQUAL "${_linked_into}") and (NOT "${_linked_into}" IN_LIST ${_target}_FRAMEWORKS). Shipped as a standalone patch file cmake4-linked-into-quoting.patch (source= entry, applied via patch -Np1 in prepare(), not inline sed – see the project’s cross-session memory on why: patch files are portable to other distros packaging the same upstream source). Bumped pkgrel only (packaging fix, not a pkgver change). Verified: cmake -S ... -B build now completes past JavaScriptCore/LLIntSettingsExtractor and produces build.ninja, full build finished cleanly (webkit2gtk, webkit2gtk-debug, webkit2gtk-docs all built, namcap only flagged pre-existing license/dependency lint issues, unrelated).

If this resurfaces in a future pkgver bump: reapply/regenerate the patch against the new source tree first (diff -Naur between vanilla and patched, verify with patch -Np1 --dry-run) – don’t assume it still applies cleanly.

2026-07-23: build-failure comment (horsemanoffaith)

AUR comment reported a CMake configure failure:

-- Found Unifdef: /usr/bin/unifdef
CMake Error at Source/cmake/WebKitMacros.cmake:311 (if):
  if given arguments:
    "(" "NOT" "_linked_into" ")" "OR" "(" "WTF" "STREQUAL" ")" "OR" "(" "NOT" "IN_LIST" "LLIntSettingsExtractor_FRAMEWORKS" ")"
  Unknown arguments specified
Call Stack (most recent call first):
  Source/cmake/WebKitMacros.cmake:393 (_WEBKIT_TARGET_LINK_FRAMEWORK)
  Source/JavaScriptCore/CMakeLists.txt:409 (WEBKIT_EXECUTABLE)

Our own build of this exact pkgver/pkgrel succeeds in the local extra-x86-build chroot (published, OVERVIEW.md shows SAME). The malformed if() argument list (empty/unquoted variable expansions, e.g. WTF STREQUAL with nothing after STREQUAL) looks like classic cmake-version-dependent if() policy behavior – likely the reporter has a much newer cmake than what’s in our chroot, and a newer policy default changes how an empty/unquoted variable inside if(... OR ...) is parsed. Not reproduced locally, so not treated as a packaging bug yet.

Next time this comes up: ask what cmake version the reporter has, and check whether cmake_minimum_required/cmake_policy pins in WebKit’s own build system need a corresponding bump in our makedepends=(cmake ...) version constraint (or a cmake_policy(SET CMP... OLD) workaround) if newer cmake becomes the norm here too.