[CMake] Accept legacy 'hipsycl' as deprecated alias for 'adaptivecpp'

[zjin-lcf]

Summary

Addresses #711.

hipSYCL was renamed to AdaptiveCpp, and #699 updated ONEMATH_SYCL_IMPLEMENTATION (and all internal references / docs) to use adaptivecpp. As a result, users following older instructions or scripts that pass -DONEMATH_SYCL_IMPLEMENTATION=hipsycl now hit a fatal error:

SYCL implementation hipsycl is not known

This PR accepts the legacy hipsycl value as a deprecated alias for adaptivecpp, emitting a deprecation warning that points users to the new value, so existing build scripts keep working:

if (ONEMATH_SYCL_IMPLEMENTATION STREQUAL "hipsycl")
  message(WARNING "ONEMATH_SYCL_IMPLEMENTATION=hipsycl is deprecated: ... Treating it as 'adaptivecpp'. Please use -DONEMATH_SYCL_IMPLEMENTATION=adaptivecpp instead.")
  set(ONEMATH_SYCL_IMPLEMENTATION "adaptivecpp")
endif()

Note: the original report (v0.9) predates #699; on current develop the docs and CMake already agree on adaptivecpp. This change only adds backward compatibility for the old spelling.

Test plan

• -DONEMATH_SYCL_IMPLEMENTATION=adaptivecpp unchanged.
• -DONEMATH_SYCL_IMPLEMENTATION=hipsycl (and hipSYCL, via existing TOLOWER) now maps to AdaptiveCpp with a deprecation warning instead of failing.
• Unknown values still produce the existing fatal error.

[sknepper]

Looks good - it makes sense to accept the hipsycl alias to preserve backward compatibility for existing build scripts.

[zjin-lcf]

Thanks.

[melonakos]

Thanks Zheming — this is a straightforward usability win and I'm happy to approve it.

I checked the surrounding logic: before this change, -DONEMATH_SYCL_IMPLEMENTATION=hipsycl fell through to the else() branch and died with FATAL_ERROR "SYCL implementation hipsycl is not known". So anyone with a build script written before the AdaptiveCpp rename got a hard failure with no hint about what to change. Now they get a clear warning and a working build. Good.

Placement is right — after the TOLOWER, before the adaptivecpp comparison — and I confirmed there are no other hipsycl references left anywhere in CMakeLists.txt, so nothing else needs updating to match.

One optional suggestion, take it or leave it: consider message(DEPRECATION ...) rather than message(WARNING ...). It's CMake's purpose-built mechanism for exactly this case, and it lets downstream users opt into strictness with -DCMAKE_ERROR_DEPRECATED=ON or quiet it with -DCMAKE_WARN_DEPRECATED=OFF. With plain WARNING they have no control. Not worth another CI cycle on its own if you'd rather leave it.

Heads up on CI: those four red ArmPL failures are not yours. Every one of them comes from a run on 2026-08-11, and ArmPL passes on runs before (Jul 28) and after (Aug 12 onward) on other PRs — it was a CI outage that day. This PR touches only CMakeLists.txt and cannot break ArmPL BLAS/LAPACK/RNG/DFT unit tests. A re-run should clear it, so please don't spend any time chasing those traces.

With this approval you should be at the two required, so a CI re-run is the only thing standing between this and a merge.

[melonakos]

Correcting myself — I got the CI diagnosis wrong above, and I want to fix that on the record before you act on it.

I said the ArmPL failures were a one-day CI outage on 2026-08-11 and that a re-run would clear them. I re-ran the aarch64 jobs today and they failed again in about 60 seconds, so that was wrong on both counts.

The real cause is the Install ArmPL step in .github/workflows/pr-arm.yml:

curl -O https://developer.arm.com/packages/arm-toolchains/ubuntu/pool/arm-toolchains-repository_2-1~noble_all.deb
sudo dpkg -i arm-toolchains-repository_2-1~noble_all.deb

That URL no longer serves the package. The download returns 361 bytes — an error page — and because curl -O is used without -f or -L, curl saves it and exits 0. The failure then surfaces one line later as:

dpkg-deb: error: 'arm-toolchains-repository_2-1~noble_all.deb' is not a Debian format archive

So this is a broken CI dependency, not a transient outage and not anything to do with your change. A re-run won't help; the workflow needs the URL updated and curl -fL so a bad download fails loudly instead of silently.

Why it hits this PR and not most of the others: the Check if the changes affect this domain filter. On PRs that only touch cuBLAS/rocBLAS sources, the ArmPL jobs skip Install ArmPL, the build, and the tests entirely — and still report green. Your PR touches build files, so the filter turns the ArmPL domain on, the install actually runs, and it fails. That also means the ArmPL "green" on your other PRs mostly means "skipped," not "passed."

The part of my earlier comment that still holds: this is not your bug and there's nothing for you to fix here. Sorry for the wrong steer on the re-run.

[melonakos]

My correction above was also wrong — the fix already exists. Here's the verified timeline, which I should have established before posting either version.

When	What
~2026-07-30	Arm republished the repo package as arm-toolchains-repository_2-2~noble_all.deb. The pinned 2-1 URL started returning a 361-byte 404 page.
2026-08-11, 02:32–16:49 UTC	The aarch64 runs on this PR (and #752, #753, #757) executed, still pinned to 2-1, and failed at Install ArmPL.
2026-08-11, 23:21 UTC	#749, "[workflows] Update ArmPL package manager installation for 26.07", merged to develop and bumped the pin to 2-2.

So the breakage was real but bounded, and it was fixed on develop about six hours after the last of these runs. There is nothing wrong with pr-arm.yml today, and my "the URL no longer serves the package, the workflow needs a 2-line fix" was simply out of date.

Why my re-run didn't clear it: re-running a workflow run replays the original commit's workflow file. Today's re-run still fetched arm-toolchains-repository_2-1~noble_all.deb — the pre-#749 version — so it failed identically. Re-running can never pick up the fix.

What actually clears it is a fresh pull_request run against current develop. Any new push to the branch does that, so if you were planning a rebase anyway it'll sort itself out. I'm going to close and immediately reopen this PR, which triggers a fresh run without you needing to do anything — if you see a close/reopen notification, that's me, and nothing about your branch has changed.

Net for you, unchanged from the start: this was never your bug and there's nothing here for you to fix. Sorry for the two-step; I should have checked the workflow's history before diagnosing it the first time.