[starkphi]

Description

project() without LANGUAGES also enables C. With CC unset, CMake picks the system cc, and because FindOpenMP caches a single OpenMP_gomp_LIBRARY for all enabled languages, the module links the system compiler's libgomp instead of the one belonging to CXX. The project now declares LANGUAGES NONE; the languages it needs (CXX, plus CUDA or HIP for GPU sources) are enabled by the enable_language calls that follow. The generated code is unchanged; only the link changes. DaCe's codegen/CMakeLists.txt has the same project(dace_program), which this PR does not touch.

Requirements

• All fixes and/or new features come with corresponding tests.
• Important design decisions have been documented in the appropriate ADR inside the docs/development/ADRs/ folder.

If this PR contains code authored by new contributors please make sure:

• The PR contains an updated version of the AUTHORS.md file adding the names of all the new contributors.

🤖 Generated with Claude Code

[starkphi]

DaCe's codegen/CMakeLists.txt has the same project(dace_program), so DaCe-compiled programs still link the system libgomp when CC is unset. Two options: fix it in DaCe (project(dace_program LANGUAGES CXX); CUDA and HIP are already added later by enable_language when needed), or have gt4py pass -DCMAKE_C_COMPILER through DaCe's compiler.extra_cmake_args (tested, it works). Which would you prefer?

[havogt]

DaCe's codegen/CMakeLists.txt has the same project(dace_program), so DaCe-compiled programs still link the system libgomp when CC is unset. Two options: fix it in DaCe (project(dace_program LANGUAGES CXX); CUDA and HIP are already added later by enable_language when needed), or have gt4py pass -DCMAKE_C_COMPILER through DaCe's compiler.extra_cmake_args (tested, it works). Which would you prefer?

If DaCe doesn't use C, then I think the fix there makes sense.