Fix CMake target clash with Abseil; add “clik_tests”

[aignermax]

Fix CMake target clash with Abseil; add “clik_tests”

Overview

Abseil 202401 introduces an interface target named check.
Our test driver used the same name, so CMake fails with CMP0002.
This patch adds a new target clik_tests that runs the existing Python test-runner and leaves Abseil’s check untouched.

Reason for change

With the current main branch + Abseil 202401 the build aborts during the configure step, so no one can compile the Construction Kit on an up-to-date toolchain.

Description of change

• Replace add_custom_target(check …) with add_custom_target(clik_tests …).
• clik_tests still depends on ClikExamples and the selected HAL.
• Tests are now launched with ninja clik_tests.
  No other targets, flags or APIs are affected.

Anything else we should know?

Verified on Ubuntu 22.04 with GCC 11, CMake 3.26, Ninja 1.11;
ninja clik_tests completes and all tests pass.

Checklist

• Project builds successfully with the change
• Tests run locally (ninja clik_tests)
• clang-format-19 run on modified files
• Code of Conduct respected

[hvdijk]

Thanks for the PR! Could you give a bit more context on this, how is Abseil being used that this causes problems? check is kind of a standard target name so I am surprised that it is causing problems. Are you including clik in an external project that also contains Abseil, or are you including Abseil in clik?

What we did when the main oneAPI Construction Kit had a check target that conflicted with a parent project's check was rename that to check-ock, but conditionally add that as a dependency to a global check target if we are not included as a subproject within LLVM, so that in the common case, the simple plain ninja check that people should generally be able to expect to work will work. Would something like that work for clik as well?

[Zebsi235]

Thanks for the detailed feedback and suggestions!

To clarify the context a bit further: we’re using Abseil alongside gRPC in the oneAPI Construction Kit as part of our HAL development process for simulated devices. Specifically, we followed the HAL REFSI tutorial and extended it with our own functionality (Memory access to our simulated device is handled over gRPC). The clik examples work fine with our HAL implementation. When progressing to the ComputeMux stage, which builds more broadly, the CMake configuration fails due to both Abseil and the OCK's test driver defining a target called check.

“Are you including clik in an external project that also contains Abseil, or are you including Abseil in clik?”
We're including Abseil into clik, rather than the other way around.

“Would something like that work for clik as well?”
I agree that a conditional approach could work and might offer a better developer experience. We actually attempted something similar—renaming the target to clik_tests and trying to hook it conditionally—but it led to cascading issues, possibly because we used a global search-and-replace rather than validating each reference manually across the repo which would have required a more detailed manual update across the repo than we had capacity for at the time.

Since we are not using gRPC directly in the OCK anymore, and therefore abseil is also not needed, this issue is not relevant for us anymore, yet we are available for questions if you think we can still provide useful information.

Thanks again for your response!

[hvdijk]

Coming back to this, rather than looking at this as a bug in oneAPI Construction Kit, I think this should be considered a bug in abseil-cpp, and others see it the same way: it is causing problems in a bunch of other projects as well, abseil/abseil-cpp#1641. And this seems like it's made unnecessarily complicated: if ABSL_ENABLE_INSTALL=OFF, the name is absl_check, if ABSL_ENABLE_INSTALL=ON, the name is check but then the output name is changed back to absl_check anyway (https://github.com/abseil/abseil-cpp/blob/master/CMake/AbseilHelpers.cmake#L310-L318). I do not understand why the name is not just always absl_check and am thinking we should not work around this in here, if we do anything it should be to help get that fixed in Abseil. But if you are no longer using it, I think we can say that this just no longer affects us.