a136b6ec98 MINGW: Define variable only when targeting Windows platforms
39c5dad0cb Ninja: Remove redundant check for GNU-like compiler on Windows
0b7ae84a96 Cygwin: Remove redundant definitions of CYGWIN and UNIX variables
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6538
The generated path with the packages uses $CPACK_TOPLEVEL_TAG, which
by default is $CPACK_SYSTEM_NAME, thus the OS name.
To make the expected stderr match also non-Linux OSes, accept any
non-slash characters in place of "Linux", so it works also on other
Debian OSes (e.g. Debian/Hurd).
The `MINGW` variable indicates that the compiler targets MinGW, a GNU
ABI on Windows. Since commit aff3147917 (Modernize GNU compiler info on
Windows, 2009-12-02, v2.8.2~636), we load the `Platform/Windows-GNU`
module for compilers targetin MinGW, so set the variable there instead.
This is equivalent to `Platform/Windows-MSVC` setting the `MSVC`
variable. Also remove `if(MINGW)` checks from the module, which have
not been necessary since the enclosed logic was moved to that module.
The undocumented `CMAKE_COMPILER_IS_MINGW` internal variable is now
unused, so remove it too.
Fixes: #22647
Update the Ninja generator's check to work using whatever language is
being enabled instead of hard-coding C and CXX. With that, the
undocumented internal `CMAKE_COMPILER_IS_MINGW` variable is only set by
compilers already covered by other alternatives in the condition. See
commit b3de0dfe93 (Ninja: Use forward slashes for any GCC on Windows,
2015-05-07, v3.3.0-rc1~93^2~3).
Since commit 58d10cf6f1 (Alternative symlink-creating mode for
file(INSTALL ...), 2021-08-02) we test creating a symlink during
configuration to decide whether to activate some tests. Capture
the process output during the check to avoid leaking the error
message on failure.
It only makes sense to use the CMake package from the same ROCm
installation that the compiler uses. Ask the HIP compiler to report the
location of the ROCm installation. Verify up front that it contains the
expected CMake package file.
Since commit bd844387df (ROCMClang: Add the ROCm toolkit derived clang
compiler to CMake, 2020-08-28, v3.21.0-rc1~66^2~6) and commit ff0d2858e1
(HIP: Extract clang compiler details from hipcc, 2020-10-21,
v3.21.0-rc1~66^2~5), the separate `ROCMClang` compiler id for `hipcc`
has caused a few problems:
* The compiler id changed from behavior of CMake 3.20 and below,
breaking projects that already built with `hipcc` treated as `Clang`.
* The implementation of `target_compile_features` was incomplete for
the `ROCMClang` identity.
* Only `hipcc` was identified as `ROCMClang`, so after it is unwrapped
to the underlying `clang++`, future runs of new CMake versions on
an existing build tree would not repeat this.
* Clang should be usable as a HIP compiler without the `hipcc` wrapper.
Remove the `ROMClang` compiler identity, and revise HIP language support
to work directly with a Clang compiler.
Reject direct `hipcc` usage as a HIP compiler. For now it cannot be
supported because it interferes with flags CMake needs to pass to Clang.
Fixes: #22536, #22460, #22593
Fail early if it is not found.
Use the detected location as a hint to find `rocm_agent_enumerator`.
Also remove the leading `_` prefix in case we want to document this
publicly later.
These are set by modules loaded for `CMAKE_SYSTEM_NAME`. We do not
need to set them again if the compiler defines `__CYGWIN__`.
Also remove the now-unused undocumented `CMAKE_COMPILER_IS_CYGWIN`
internal variable.
