On Windows systems, the need to retain library directories should not
nomrally occur. This can only occur on Unix like systems where a shared
library is being linked that has a dependency on another library which
is not being found in the default directories (e.g. libgfortran on BSD)
This also works around an issue introduced by !1694 in that the Visual
Studio generator does not handle link flags passed in
`INTERFACE_LINK_LIBRARIES` correctly, causing problems when using that
generator with Intel MPI in certain circumstances.
Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
abstraction to select the runtime library from an enumeration of logical
names. We've long hesitated to do this because the idea of "runtime
library selection" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.
Removing the old default flags requires a policy because existing
projects may rely on string processing to edit them and choose a runtime
library under the old behavior. Add policy CMP0091 to provide
compatibility.
Fixes: #19108
The Gentoo case added by commit 1673923c30 (FindBoost: Add support for
Boost 1.67 with Python version suffixes, 2018-03-18, v3.11.0~3^2) left
out the `.` version component separator and instead duplicated the RPM
case. Add the missing `.` now.
Fixes: #18743
VS 2019 Update 1 will fix its redist directories to be named `VC142`
instead of `VC141`. It will also use cl `19.21` instead of `19.20`
so we can use that to distinguish the versions.
Fixes: #19131
032e969879 Merge branch 'backport-FindBoost-msvc-toolset-14.2'
717e85418b FindBoost: Add support for MSVC toolset version 14.2
9010f5c18a FindBoost: Add support for MSVC toolset version 14.2
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3221
Use the infrastructure added by commit f92ccbc306
(CompileFeatures: memoize C compilers with full language level support)
to avoid using a `try_compile` to check for C 90/99/11 feature support when the running compiler is known to have a fixed set of feature support.
-- When using default values for the external project forward GHS platform
variables so that the external project builds with the same tools as
the original project.
-- Fix issue with bad top level project when GHS_PRIMARY_TARGET is set but has
no value. In this case treat it as unset and use default value.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++98 feature support when the
running compiler is known to have all features.
613ac56e50 Add a test to verify meta-feature parity with granular features
b0f46c48f6 CompileFeatures: Now able to presume full language level support
646fb1a646 CompileFeatures: memoize C++ compilers with full language level support
0d641fcfad Tests: Remove outdated portion of CompileFeatures genex test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3176
Previously compilers that only supported the meta-level flags
would not have any of the granular features listed. Now we
presume that they have full support and enable all the features.
Update granular feature tests to skip the actual compilation
checks for the presumed features.
Previously compilers that had full support for a language standard level
were still verified every time a new build directory was created. Now
we record this information and insert the correct granular compile
features instead of doing a `try_compile`.
In some cases GCC reports *relative* implicit include directories. They
are computed adaptively with respect to the current working directory
such that the effective implicit include directory is an unchanging
absolute path. Teach our implicit include directory extraction to
recognize such paths and normalize them.
Fixes: #19133
Since VS 2017's v141 toolset there is no longer a simple equation to
calculate the redist name, dll version, and VS IDE version from just the
MSVC toolset version. Refactor the logic to use hard-coded values and
warn when a new version is not supported.
Fixes: #19125
Since commit 8f8d056051 (ARMCC: Fix identification of ARM compiler when
it defines GNU macros, 2019-03-20, v3.14.1~10^2) we consider ARMCC
before Clang or GNU compilers. Since armclang also defines
`__ARMCC_VERSION` it is now mistaken for ARMCC. Extend the check for
ARMCC to also verify that `__clang__` is not defined.
Issue: #19065
This was forgotten in commit 626c51f47b (VS: Update for Visual Studio
2019 Preview 2, 2019-01-24, v3.14.0-rc1~74^2) when the toolset was
first renumbered to `v142`.
Issue: #19125
FindGLEW temporarily changes the content of CMAKE_FIND_LIBRARY_SUFFIXES
to look for static and dynamic GLEW library.
However, it wasn't storing and restoring the initial content of such
variable, causing possible issues in user project.
983533a4b8 Record when C compilers have gained full support for 90,99,11
f92ccbc306 CompileFeatures: memoize C compilers with full language level support
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3146
When a dependency was already found, find_dependency did not search it
again. While this works in basic case, it does not when there are
components as the check does not take components into account.
Given the fact that there is no documentation about this optimization and
that the correct implementation is not trivial as it would require
changes in find_package to have the list of components already found we
always search dependencies.
Fix#17583.
-- Rename platform script so it runs before initial try_compile() in
project() command.
-- Fix incorrect variable name GHS_OS_DIR_OPTION
-- Remove unnecessary ".*" from REGEX expression for GHS_CANDIDATE_OS_DIRS
-- Forward GHS_OS_DIR_OPTION to try_compile() and preserve trailing
whitespace of the variable.
