[Claude] add .claude with web session setup scripts - #2128
Conversation
* Add Claude Code on the web session-start hook Installs the system deps (Boost.context/fiber, LLVM headers, OpenMPI, pre-commit), initializes submodules, and builds AdaptiveCpp + Shamrock (debian-generic.acpp, OpenMP backend) so tests and linters are ready in web sessions. Also fixes get_acpp_target_env(), which raised a TypeError when --backend was omitted because it never returned the default "omp" value. Assisted-by: Claude * Skip the full Shamrock build in the session-start hook A full `shammake` compiles all 462 targets (~40min); only run shamconfigure (which still builds the AdaptiveCpp compiler once) so the session starts quickly, and let Claude build only the target(s) touched by a change, doing a full build/test binary only when tests or the `shamrock` executable are actually needed. Assisted-by: Claude * Document incremental builds in AGENTS.md A full shammake takes ~40min; note that only the touched target should be built (ninja -t targets all lists them), reserving a full build for when tests need to run or the binary needs to execute. Mirrors the same policy now used by the session-start hook. Assisted-by: Claude * Harden session-start hook for the setup-script-box path - Tolerate apt-get update failures: some base images ship extra PPAs (deadsnakes, ondrej/php) that this environment's network policy 403s, which apt escalates to a hard error and previously aborted the whole script under set -e even though the mirrors we need succeed. - Skip the cd into CLAUDE_PROJECT_DIR when it's unset, which happens when the script is pasted into an environment's setup-script box instead of running through the normal session bootstrap. Same treatment for the CLAUDE_ENV_FILE write. Assisted-by: Claude --------- Co-authored-by: Claude <[email protected]>
shamconfigure/pull_reffiles previously ran on every session start, and the AdaptiveCpp compile they trigger on a fresh container takes a few minutes, blocking the whole session on it. The hook now stops after new-env (fast: just generates activate/shamenv_do, no compile) and lets the first real build or test request pay that one-time cost inline via the existing idempotent shamconfigure/shammake guards. Also parallelize the submodule fetch with --jobs. Assisted-by: Claude Co-authored-by: Claude <[email protected]>
Installs clangd-18 alongside the existing AdaptiveCpp/MPI/pre-commit deps and symlinks it to an unversioned `clangd` on PATH, since the Ubuntu package only ships the versioned binary. It picks up build/compile_commands.json (from shamconfigure) and the repo's .clangd config with no extra setup. Assisted-by: Claude
clangd --check on this Ubuntu clangd-18 build only surfaces hard parse errors — verified that plain -Wconversion warnings and .clang-tidy findings never reach its output, even with --clang-tidy forced. Correct CLAUDE.md to say so, and add .claude/tools/clang-tidy-check.py, which strips the SYCL/acpp flags clang-tidy can't parse (mirroring .clangd's CompileFlags.Remove list) and runs clang-tidy-18 directly against a file's build/compile_commands.json entry. Assisted-by: Claude
Ubuntu noble's own repos offer clang/clangd/clang-tidy up to 20 with no external PPA; apt.llvm.org (which would reach the newer releases the .clangd file's >= clangd-21/22 comments and the pre-commit-pinned clang-format v22.1.8 imply) is blocked by this environment's network policy, so 20 is the closest reachable match. Installed as a toolchain fully separate from llvm-18-dev, which stays pinned since that's what AdaptiveCpp is actually built and cached against here — upgrading dev tooling should never risk the build. Verified clangd-20 fixes the .clang-format AlignCaseArrows parse error clangd-18 hit, but --check still only surfaces hard parse errors (not warnings or clang-tidy findings) at 20 same as 18, so clang-tidy-check.py remains the way to get real clang-tidy diagnostics; updated it to invoke clang-tidy-20/clang++-20. Assisted-by: Claude
AdaptiveCpp's CMakeLists.txt supports LLVM up to major version 20 (SEND_ERROR above that without -DACPP_EXPERIMENTAL_LLVM=ON), so there's no need to keep 18 around just for the build once 20 is available. Purged all llvm-18/clang-18/clangd-18 packages, rebuilt AdaptiveCpp from scratch against llvm-20-dev/libclang-20-dev/libomp-20-dev, and verified end-to-end: shamconfigure picks up "Building AdaptiveCpp against LLVM configured from /usr/lib/llvm-20", shammake shamrock links cleanly, and the resulting binary runs. session-start.sh now installs only the LLVM 20 dev packages (plus clang-20/clangd-20/clang-tidy-20 for tooling) instead of a split 18-for-build/20-for-tools setup. Assisted-by: Claude
Drop the "verified end-to-end after purging..." and "verified this holds on both clangd-18 and clangd-20" asides — process history, not information useful to a future session. Assisted-by: Claude
Hardcoding clang-tidy-20/clang++-20 only worked inside this container. Outside Claude Code on the web, the host may have a different (or no) LLVM 20 install. Pick the newest matching clang-tidy-N/clang++-N pair found on PATH instead, falling back to unversioned names, so the script works wherever a clang-tidy/clang++ toolchain is installed. Assisted-by: Claude
That script already does this correctly: it expands each acpp compile command via `acpp --acpp-dryrun` into the actual plain-clang invocation (rather than guessing which flags to strip) and drops plugin flags clang-tidy can't load — it's the same database CI's clang-tidy job builds and runs against. clang-tidy-check.py now regenerates build/clang-tidy.mod when missing or stale and runs the newest clang-tidy found on PATH against it, replacing the previous hand-rolled SYCL-flag-stripping logic. Assisted-by: Claude
|
Thanks @tdavidcl for opening this PR! You can do multiple things directly here: Once the workflow completes a message will appear displaying informations related to the run. Also the PR gets automatically reviewed by gemini, you can: |
|
Warning Review limit reached
Next review available in: 36 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The repo's check_no_utf8 hook rejects non-ASCII characters in .py files; swap the em dash for a plain hyphen. Assisted-by: Claude
|
@Mergifyio queue |
Merge Queue Status
This pull request spent 5 hours 53 minutes 27 seconds in the queue, including 2 hours 9 minutes 50 seconds running CI. Required conditions to merge
|
Workflow reportworkflow report corresponding to commit aaf2a54 Light CI is enabled (the default for pull requests). This will only run the basic tests and not the full tests. Pre-commit check reportPre-commit check: ✅ Test pipeline can run. Clang-tidy diff reportNo relevant changes found. You should now go back to your normal life and enjoy a hopefully sunny day while waiting for the review. Doxygen diff with
|
No description provided.