The sdcc compiler no longer defines the `SDCC` preprocessor macro.
Instead `__SDCC_VERSION_MAJOR` and similar component-wise macros are
defined. Use them instead if defined.
Issue: #16746
In commit v3.8.0-rc1~304^2 (MSVC: Do not define _DEBUG explicitly when
using /MDd, 2016-11-15) we removed the `_DEBUG` preprocessor definition
from MSVC C and C++ flags because the `cl` compiler automatically
defines it in Debug builds anyway. However, the VS generators propagate
C preprocessor definitions to the RC (Windows Resource Compiler) tool.
This means that we used to explicitly define `_DEBUG` for RC debug
builds. Therefore existing project code may expect the definition to be
there even though the `rc` compiler itself does not implicitly define
`_DEBUG` in debug builds.
Add the `_DEBUG` flag to the default `CMAKE_RC_FLAGS_DEBUG` instead
to restore this definition for RC debug builds. This also makes it
available consistently in VS, Ninja, and Makefile generators.
Fixes: #16745
The VS generators use the C (or CXX) preprocessor definitions for
the Windows Resource Compiler tool. This causes definitions parsed
out of `CMAKE_RC_FLAGS[_<CONFIG>]` variables to be dropped. Fix
the implementation to preserve both.
Issue: #16745
The `sysconf(3)` manual explains that the return value can be `-1` for
limits if there is no definite limit. Recognize this case and skip
using the value as a limit candidate. Otherwise we use response files
unconditionally on such systems instead of checking other limits.
Fixes: #16740
Use our undocumented `cmake_host_system_information` query to find the
VS 2017 installation directory by asking the VS installer tool. Then
look relative to that for the redist directory.
Fixes: #16737
Add a query to the `cmake_host_system_information` command to get
the location of a VS 2017 installation. Leave it undocumented and
for internal use for now.
Build id links generation was introduced
in rpm 4.13.0.1 so files related to them
should be ignored as they are not relevant
for the tests.
Fixes#16710
VS 2017 (VS 15) places its redist DLLs in `Microsoft.VC150.*`
directories but still uses version number `140` in the DLL names. The
redist directories now have version numbers in their name, and the MSVC
and MFC runtime DLLs may be in directories with different versions.
Fill out our logic to handle this.
For now assume we are given the `MSVC_REDIST_DIR` value as a cache
entry. Unfortunately we cannot yet find the VS 2017 MSVC redist
directory automatically since there is no registry entry for the VS
installation. Later we will have to use `cmVSSetupHelper` for this.
Issue: #16735
Each `MSVC${v}_*_DIR` variable is only ever used with one value for
`${v}` within a given build tree. Drop the `${v}` version component
from the variable names.
For a given `MSVC_VERSION` our macros were each called at most once.
Replace them with a single code path that is parameterized over what
was the macro argument.
Brad King