| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The prefix does not have two colons. Update our regex.
Fixes: #24357
|
|
|
|
| |
Also avoid running the detection multiple times.
|
|
|
|
|
|
|
|
| |
Replace old-style `file(APPEND .../CMake{Output,Error}.log)` logging
with calls to `message(CONFIGURE_LOG)` to record the steps in the
`CMakeConfigureLog.yaml` configure log instead.
Issue: #23200
|
| |
|
|
|
|
|
|
| |
Changes in commit 9c5bd7fe3a (CompilerId: Output errors from all
attempts at detection, 2022-08-16, v3.25.0-rc1~290^2) accidentally
stopped logging failed compiler identification build output.
|
|
|
|
|
|
|
| |
The `GNU` and `MSVC` compilers obviously use their own front-end
command-line style. Also set this for `AppleClang`.
Fixes: #24232
|
|
|
|
|
|
|
|
|
| |
Generalize the fix from commit 37a279f8d1 (Ninja: Write msvc_deps_prefix
as UTF-8 when console codepage is UTF-8, 2020-07-31, v3.19.0-rc1~349^2).
`cl /showIncludes` output is encoded using the console output code page,
so this is the byte sequence that Ninja must use to match its lines.
Fixes: #24068
|
|
|
|
|
| |
Instead of printing the output of the last attempt, print
the output of all attempts. This shows users that CMake isn't ignoring any provided flags ( LANG_FLAGS ).
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
627c08e28b Tests: Teach RunCMake to ignore Xcode DVTSDK warnings
ab40020b17 Xcode: Suppress "Run Script" build phase warning during compiler id
89e1113e0c Xcode: Use ad-hoc signing during compiler id on macOS
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7350
|
| |
| |
| |
| |
| |
| |
| |
| | |
Xcode 14 no longer accepts an empty signing identity for macOS.
However, Xcode in general does not accept an ad-hoc signing
identity for iOS. Switch based on the target platform.
Fixes: #23609
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
612c0d49f4 VS: Fix detecting icx.exe with Intel Compiler toolsets newer than 2021
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6806
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Verifying the architectures during compiler identification is redundant,
and requires a lot more up-front information than we should need.
It also causes unsupported architectures to break the compiler id and
version detection, so the resulting output from CMake does not report
the compiler version, which is useful information to know why the
specified architectures are not supported.
The "detecting compiler ABI info" and "check for working compiler" steps
already pass `CMAKE_CUDA_ARCHITECTURES` into their test projects.
Therefore we can just drop the earlier architecture testing. Bad
architectures will be reported as a not-working compiler, and the
output will include the compiler's error message.
This reverts the approach from:
* commit 19cc5bc296 (CUDA: Throw error if user-specified architectures
don't work, 2020-05-26, v3.18.0-rc1~79^2)
* commit 650c1029a0 (CUDA: Detect non-working user-specified architectures
on NVCC, 2020-05-28, v3.18.0-rc1~51^2)
* commit 01428c5560 (CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES
doesn't work during detection,
2020-08-29, v3.19.0-rc1~241^2).
Their goal was in part to avoid waiting until the test for working
compiler to detect unsupported architectures. However, experience has
shown that failing earlier is more trouble than it's worth.
Fixes: #23161
Issue: #20756
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
CUDA 11.6 added the `nvcc -arch=native` flag to automatically compile
for the host GPUs' architectures. Add support for specifying this
special `native` value in `CMAKE_CUDA_ARCHITECTURES` and
`CUDA_ARCHITECTURES`. During the compiler ABI detection step,
detect the native architectures so we can pass them explicitly
when using Clang or older versions of nvcc.
Fixes: #22375
|
| | |
| | |
| | |
| | | |
Fixes: #23309
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Skip the architecture verification check for these values on Visual
Studio. It cannot be implemented correctly until future work delays the
check to the main compiler test step.
Issue: #23164, #23161
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | | |
612c0d49f4 VS: Fix detecting icx.exe with Intel Compiler toolsets newer than 2021
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6806
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The logic added by commit 7808cbd644 (CMakeDetermineCompilerId: support
Intel DPC++ compiler toolset for VS gen, 2020-12-06, v3.20.0-rc1~330^2)
matches a specific toolset known to be the `icx.exe` compiler, and
assumes all other Intel C++ compilers (that are not DPC++) must be
`icl.exe`.
Since `icx.exe` is officially replacing `icl.exe`, use a regex that
matches the now-fixed set of toolsets known to use `icl.exe`. Any other
Intel C++ compiler will be assumed to be `icx.exe`.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Changes to ``-A`` handling:
* Don't force CMAKE_GENERATOR_PLATFORM into cache when using default
value (breaks using CMake presets).
* Don't print message when using default value (breaks CMake tests).
Changes to ``GHS_PRIMARY_TARGET`` handling:
* Add as a cache variable so its known to GUI
* Don't always include``GHS_TARGET_PLATFORM``, it's only needed if
``GHS_PRIMARY_TARGET`` wasn't set by the user.
* Set ``GHS_PRIMARY_TARGET`` during platform selection instead of when
a language is enabled. By performing this sooner
``GHS_TARGET_PLATFORM`` is not always required to be set into cache.
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
d51246c662 VS: Default TargetFrameworkVersion to v4.7.2 for VS 2022
f97f8537f3 VS: Model a default target framework
e40cedddc0 cmVisualStudio10TargetGenerator: Refactor target framework selection
78782cc7dc cmGlobalVisualStudio8Generator: Refactor SetGeneratorPlatform
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6699
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add fields to the VS generator to select a target framework.
Migrate the existing default for VS 12 .NET CF for Windows CE.
Report the values in `CMAKE_VS_*` variables and use them for
the CSharp compiler id project too.
Issue: #22849
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If one uses `CFLAGS='-std=...'` or `CXXFLAGS='-std=...'` then the given
`-std=` flag(s) will always be used. That effectively changes the
compiler default standard level and extension settings. Fix the
Xcode generator's compiler id logic to preserve any `-std=` flag
so that the proper defaults are detected.
This problem was exposed by commit 4a0485be7f (cmStandardLevelResolver:
Avoid unnecessary flags, fix unset level logic, 2021-05-29), which
changed the logic to not pass any `-std=` flag if the standard level
and extension settings requested by the project match the default
(`stdIt <= defaultStdIt` became `stdIt < defaultStdIt`). The new
logic assumes the detected default standard matches what will actually
happen when the project is generated.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
In Linux C++ terms dialect usually refers to having GNU extensions or not.
Change the name to better reflect that this is about the standard version.
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
cb93f72624 HIP: Simplify detection of HIP runtime CMake package
a71f0fc9c7 HIP: Remove ROMClang compiler id and use Clang directly
b125e9809a HIP: Detect ROCm path earlier
735f41fc2d HIP: Use 'rocm_agent_enumerator' to determine CMAKE_HIP_ARCHITECTURES
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Acked-by: Raul Tambre <raul@tambre.ee>
Acked-by: Axel Huebl <axel.huebl@plasma.ninja>
Merge-request: !6533
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| |/
| |
| |
| |
| |
| | |
f75610d492 CMakeDetermineCompilerId: Fix CMAKE_EXECUTABLE_FORMAT in CMP0126 NEW behavior
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6364
|
| |
| |
| |
| |
| |
| |
| |
| | |
Setting `CMAKE_EXECUTABLE_FORMAT` as a normal variable is unnecessary
because setting it as a cache entry already makes the value visible to
the calling scope.
Fixes: #22433
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
3953dfcb31 Restore support for backslashes in initial language-wide flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5995
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Refactoring in commit bdc40742bd (CMakeDetermineCompilerId: Test without
COMPILER_ID_FLAGS if REQUIRE_SUCCESS, 2021-02-27, v3.20.0-rc3~6^2) added
an extra macro layer through which flag strings are passed. That caused
an extra level of argument re-parsing, and broke flags with backslashes.
Pass flags to the helper macro through variable names instead.
Fixes: #22041
|
| |
| |
| |
| | |
Co-Author: Yuichiro Utsumi <utsumi.yuichiro@jp.fujitsu.com>
|
|/
|
|
| |
Fixes: #21170
|
|
|
|
| |
Need to quote the list expansion otherwise we'll try each argument separately.
|
|
|
|
|
|
|
| |
If we REQUIRE_SUCCESS, i.e. TEST_FLAGS_FIRST must work, we need to also try
without user flags.
Fixes #21869.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using a single ID 'IntelLLVM' for the suite of Intel compilers based on
the LLVM backend. The 'IntelLLVM' ID are used for C, C++, and Fortran.
Data Parallel C++ will be handled in a separate commit.
The C and C++ definitions are based on the Clang definitions. The Intel
LLVM-based C and C++ compilers are based on the Clang front end, so
existing Clang options are more likely to be a good match than options
for the older Intel compilers.
Fortran is based on the older Fortran front end with the LLVM backend.
It has a similar interface to the older versions, though many options
are shared with the C and C++ compilers.
Fixes: #21561
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
|
|
|
| |
Fixes: #21607
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before Intel have only one compiler icl (Intel(R) C++ compiler) and
CMakeDetermineCompilerId has considered, that all toolchains with a word
"Intel" in the toolchain name is a icl compiler. But now Intel have also other
compiler - Intel(R) DPC++ compiler, which haven't working with cmake on
Visual Studio Generator because cmake try to use icl compiler, which cmake
can't found and because of this fails the configuration. This commit fix
this problem, and both compilers start to work correctly with
Visual Studio generator.
Fixes: #21546
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
f25ac39dee CMakeDetermineCompilerId: Tolerate stray text around INFO strings
5cb66f17ca CMakeDetermineCompilerId: Add whitespace to clarify logic
1ee99104f7 CMakeDetermineCompilerId: Filter IAR-AVR format INFO strings earlier
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5570
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When cross-compiling with Xcode our compiler id test binary may be
compiled with multiple architectures. The INFO strings should be
identical and therefore de-duplicated. However, this can be broken by
stray text that happens to sit immediately before or after an INFO
string. Filter out such text so we can match clean INFO strings.
Fixes: #21526
|
| |
| |
| |
| | |
Also initialize a variable closer to its use.
|