Fixes build project error because the OS directory was a relative
path from the binary directory.
Fixes issue during project regeneration where the `-os_dir` project option
was missing because GHS_OS_DIR was not properly stored in the cache
file.
This error was introduced by commit aa59eaac4f (GHS: Allow setting GHS
variables from toolchain file, 2021-11-15, v3.23.0-rc1~337^2).
To be more consistent between genex and variables as well as
the forecomming LINK_GROUP genex, rename variable *_LINK_USING_<FEATURE>*
in *_LINK_LIBRARY_USING_<FEATURE>*
In commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based
compilers, 2020-11-02, v3.20.0-rc1~89^2~20) the IntelLLVM depfile
generation flags were taken from `Platform/Windows-Intel-C`. Those
flags were added by commit a624a3e1b3 (Ninja: Use deps=gcc for Intel
Compiler on Windows, 2019-01-30, v3.14.0-rc1~30^2), which forgot to
account for commit 6d74e7870b (Ninja: Add dependencies on
system-provided header files, 2016-03-15, v3.6.0-rc1~265^2).
The `-QMD` option generates Makefile dependencies. The `-QMMD` option
generates Makefile dependencies, but excludes system header files.
Part of the BuildDepends test includes a header, cmake_pch.hxx, that
includes a second header, zot_pch.hxx. The test builds a pch file for
cmake_pch.hxx, touches zot_pch.hxx, then verifes that cmake_pch.hxx.pch
is regenerated based on the dependencies.
The cmake_pch.hxx contains `#pragma system_header` before it includes
zot_pch.hxx. `#pragma system_header` indicates that the portion of the
file following the pragma is to be treated as a system header.
When `-QMMD` is used to generate dependencies, the `#include` of
zot_pch.hxx is ignored because it `-QMMD` says to ignore system headers.
Using `-QMD` instead uses all headers when generating dependencies
and causes this test to pass. The Clang configuration in
Platform/Windows-Clang.cmake also uses the `-MD` option for generating
pre-compiled headers, instead of `-MMD`.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
In commit a624a3e1b3 (Ninja: Use deps=gcc for Intel Compiler on Windows,
2019-01-30, v3.14.0-rc1~30^2) we forgot to account for commit 6d74e7870b
(Ninja: Add dependencies on system-provided header files, 2016-03-15,
v3.6.0-rc1~265^2).
Use of `-fvisibility=hidden` fails:
unsupported option '-fvisibility=hidden' for target 'powerpc-ibm-aix7.2.0.0'
Apply the change from commit 4feba34d02 (GNU: Do not use -fvisibility on
AIX or HP-UX, 2016-09-03, v3.7.0-rc1~173^2~2) to IBMClang also.
Issue: #23157
For IntelLLVM, linking with the compiler driver is preferred over using
the linker directly. This is especially true when doing offload to a
target accelerator, which can produce object files that the regular
linker will not handle properly.
Windows-IntelLLVM relies on Windows-MSVC.cmake for many definitions.
This commit does not change that, but does override the MSVC defaults
for linking executables, shared libraries, and static libraries so that
CMake will use the compiler driver instead of the linker.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
The `cmcldeps` executable is only built on Windows. If running MSVC on
a different OS (with various compatibility wrapping), don't try to use
`cmcldeps`, as the executable doesn't exist.
Fixes: #21760
Update the support added by commit 4ea3a88625 (MSVC: Add support for
targeting ARM64EC, 2020-12-30, v3.20.0-rc1~121^2).
Add `softintrin.lib` to `CMAKE_C_STANDARD_LIBRARIES_INIT`.
Remove `/D_ARM64EC_WORKAROUND` from the flags as it was only ever needed
in preview versions of VS.
Issue: #21724
* Update generator to use the current variable definition,
not the CACHE definition.
* Avoid overwriting toolchain variables and avoid developer warnings
when setting up the GHS variables.
-- A cache entry is only required when:
a) The toolchain uses set( CACHE ) to set the variable
b) A -D or preset value was used to set the variable
The cache entry is required so that the TYPE gets set properly.
-- Avoid the Policy CMP0126 warnings:
setting cache variable when normal variable exists
* Move GHS_PRIMARY_TARGET back into area so non-GHS generator
toolchain file can trigger the OS search.
Selection of a BSP only needs to be performed if not set by user.
Remove all the logic for printing error and status messages about BSP
selection. These messages also breaks CMake tests.
NOTE: If BSP selection fails then the compiler checks will result in
a build error. The build error will report that the BSP does not exist.
Selection of an RTOS only needs to be performed if not set by user.
Avoid CMake developer warnings for setting GHS_OS_DIR multiple times.
Instead only set it once after searching has been performed.
Remove all the logic for printing error and status messages about RTOS
selection. This was broken and reporting incorrect messages. These
messages also breaks CMake tests.
NOTE: If RTOS selection fails then the compiler checks will result in
a build error. The build error will report that the RTOS
"GHS_OS_DIR-NOT-SPECIFIED" does not exist.
-- Ensure that GHS_TOOLSET_ROOT is used as a path
* Converts directory path slashes to CMake style
-- Use ComparePath() to properly check for path changes of build tool
* Accounts for Windows file-system case insensitivity.
-- Don't print message "defaulting" messages (this causes CMake test failures)
-- Don't force update CMAKE_GENERATOR_TOOLSET back into cache when `-T`
is not used on initial configure. This change avoids an unnessary
error message when accidentally using `-T` in subsequent runs but the same
tools are always used.
-- Use IssueMessage() for error messages.
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.
Extend the logic from commit 08c5b3eff0 (GNUtoMS: Add search path for VS
2019 environment scripts, 2020-01-09, v3.16.3~15^2) to consider VS 2022
paths too.
Fixes: #22847
Since commit 6051a49c78 (Visual Studio: Add Android support, 2020-06-12,
v3.19.0-rc1~619^2) we run MSBuild to build a sample project to detect
the sysroot. Previously we relied on `CMAKE_VS_MSBUILD_COMMAND` being
available. That required commit d5b5c19278 (cmGlobalGenerator:
FindMakeProgram() before CMakeDetermineSystem, 2020-06-15,
v3.19.0-rc1~619^2~3) to make it available early enough. However, that
ordering broke `CMAKE_GENERATOR_INSTANCE` so we need to prepare to
revert it. Use `cmake_host_system_information` to get the location of
MSBuild under a VS generator instead.
The target properties `CUDA_SEPARABLE_COMPILATION` and `CUDA_PTX_COMPILATION`
now aren't mutually exclusive and can now be used together on the same
target.
The `.elf` extension is a common convention used for embedded binaries.
Both Arm and RISC-V use the ELF file format for executables.
Configuring the `.elf` file extension is typically done incorrectly.
Most embedded developers set this in toolchain files, which is not
the correct place.
This is typically accomplished through a hack by setting the individual
language file extensions for C, CXX, and ASM.
Multiple CMake issues in the past have been opened related to this.
* #16538
* #20163
* #17880
A platform module makes it simpler and less error prone for developers
targeting these ubiquitous bare-metal platforms.
This PR attempts to solve this globally with a generic platform.
This could also be solved by using more specific platform modules, such
as one for each of bare-metal Arm and RISC-V.
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.
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 `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
Since commit a7f41a7ee4 (Android: Fix find_* search order within NDK for
unified toolchains, 2020-10-13, v3.20.0-rc1~610^2), we turn off
`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`. This breaks `find_program`
searching `PATH` for host executables. Fortunately, the setting turns
out not to be necessary, perhaps since commit cbc51a8be3 (Android:
restructure android search paths, 2020-11-06, v3.20.0-rc1~509^2).
Without it, none of NDK tests fail, so remove it to restore pre-3.20
behavior.
Fixes: #22634
This was forgotten in commit 0c7f918fb1 (VS: Update Visual Studio 17
2022 generator for Preview 2, 2021-07-14, v3.21.1~29^2) when the toolset
was first renumbered to `v143`.
Fixes: #22585
Since commit 4aed96e230 (Apple: Set CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG
on non-macOS too, 2021-04-06, v3.20.1~5^2) we always enable support for
linking with `-rpath`. The intention of the change was to enable using
the flag on iOS, tvOS and watchOS by avoiding a Darwin-specific version
check. However, removing the check broke support for OS X 10.4 because
the flag is not supported on that version.
Restore a form of the check that disables the flag on OS X < 10.5 while
still allowing it for the other Apple platforms. Since no one is doing
iOS/tvOS/etc development on 10.4, this change should have no unintended
side effects.
Fixes: #22490
The behavior was added by commit 7ebc1cb2ff (Haiku: Several fixes to
platform module, 2013-10-05, v3.0.0-rc1~541^2~3), but was not explained
in its commit message. No other platform modules do this.
The include-once behavior results in incorrect variables set in some
larger projects, e.g. .NET Core, particularly when cross-compiling,
`CMAKE_DL_LIBS` being one of these. Remove it.
