Skip to content

ci: put Homebrew on PATH in the pastrami job - #7

Merged
pvelesko merged 4 commits into
mainfrom
ci-pastrami-homebrew-path
Oct 14, 2026
Merged

pvelesko merged 4 commits into
mainfrom
ci-pastrami-homebrew-path

Conversation

@pvelesko

Copy link
Copy Markdown
Collaborator

The pastrami runner starts jobs without /opt/homebrew/bin on PATH, so the macOS job fails at its first cmake call with "cmake: command not found". Export the Homebrew prefix like chipStar's own pastrami workflows do.

This PR was generated using AI

The pastrami runner starts jobs without /opt/homebrew/bin on PATH, so the
macOS job died at its first cmake call ("cmake: command not found",
exit 127) before building anything. chipStar's own pastrami workflows
export the same prefix for this reason.
The pastrami runner's .env sets SDKROOT to the Command Line Tools SDK.
With SDKROOT (or an -isysroot, which Homebrew CMake 4.1 adds when SDKROOT
is unset) and no deployment target, the assertion-enabled LLVM 22 build
at ~/install/llvm/22.0-native aborts on any HIP compile:

  Assertion failed: (!TargetInitialized && "Target already initialized!"),
  function setTarget, file Darwin.h

from Darwin::AddDeploymentTarget, reached once for the host toolchain
and again for the offload job. CMake's compiler check therefore fails.
The -arch arm64 in the log is CMake's default on Apple Silicon
(_CMAKE_APPLE_ARCHS_DEFAULT in Platform/Darwin-Initialize.cmake) and is
not the trigger: plain `hipcc -c` asserts the same way with SDKROOT set.

Giving clang a deployment target (MACOSX_DEPLOYMENT_TARGET, which CMake
also turns into -mmacosx-version-min) skips the SDK-derived path and the
assertion. 15.0 matches the 15.5 Command Line Tools SDK.
Every device compile that includes a macOS SDK header (gtest pulls in
AvailabilityMacros.h) fails on pastrami with

  TargetConditionals.h:353: error: unrecognized arch using compiler
  with __is_target_arch support

chipStar works around this by adding
-Xarch_device -I<dir>/include/hip/devicelib/macOS, whose stub
TargetConditionals.h shadows the SDK one for spirv64. But chipStar's
CMakeLists.txt bakes ${CMAKE_SOURCE_DIR} into the installed .hipInfo,
so the pastrami install points at /Users/paulius/chipStar-main, a
source tree that no longer exists. The same header is installed under
<prefix>/include/hip/devicelib/macOS, so append that path through
hipcc's HIPCC_COMPILE_FLAGS_APPEND.
rocPRIM's meatloaf job has failed in CMake's compiler check since at
least 2026-08-07:

  clang++: error: cannot find HIP device library for 'spirv64' target
  clang++: error: cannot find HIP runtime

~/install/HIP/chipStar/main on meatloaf was installed from a chipStar
CI build configured with the prefix /tmp/chipstar-ci-staging/1460/
chipStar/ci. Its share/.hipInfo (HIP_PATH, --hip-path, -include, -L,
rpath) and lib/cmake/hip/hip-targets.cmake (_IMPORT_PREFIX, so
hip::CHIP -> .../ci/lib/libCHIP.so) name that staging dir, which has
since been reaped. chipStar main fixed the generator side in
7a0fd3fe06d3 ("cmake: resolve the install prefix in generated files at
install time"), but this install predates it.

hipcc reads .hipInfo from bin/../share before $HIP_PATH/share, so the
module's HIP_PATH cannot override it. Copy hipcc, .hipInfo and the hip
CMake package into $RUNNER_TEMP, rewrite the stale prefix to the real
one, and point CMake at the copies. Everything else (headers, libCHIP,
device libraries) is used from the install. With a correct install the
sed is a no-op.

Pinning the only other install on meatloaf, HIP/chipStar/2026.04.08,
was tried and rejected: it configures, but rocprim.warp_scan fails
ExclusiveScan/Scan for warp_params<signed char|unsigned char, 32, 1>,
which pass with this install. These lines can go once
HIP/chipStar/main on meatloaf is reinstalled.
@pvelesko
pvelesko force-pushed the ci-pastrami-homebrew-path branch from b532bb8 to bad606b Compare October 14, 2026 03:46
@pvelesko
pvelesko merged commit 01124df into main Oct 14, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant