Fix logic added by commit a7d853868b (FindGLEW: Update implementation,
2019-03-13, v3.15.0-rc1~375^2~1) on macOS. macOS is recognized as both
UNIX and APPLE. Consequently, the library suffix for shared and static
library was set, respectively, as `.so` and `.a`, just like UNIX systems.
Fix this by properly checking the OS type.
Fixes: #19542
Since commit d44c0db0b2 (clang: setup correct configuration in gnu mode,
2019-02-20, v3.15.0-rc1~41^2~5) our Clang compiler information modules
need the `CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT` variable that we
compute during compiler detection. However, some existing toolchain
files set our internal `CMAKE_<LANG>_COMPILER_ID_RUN` variables and
block that detection, but do not set the new frontend variant variable.
Help them out by setting `CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT` anyway.
Fixes: #19515, #19539
The `CMAKE_LINK_LIBRARY_FILE_FLAG` variable is meant for linkers that
want library file paths to be preceded by a flag. This is used only
for OpenWatcom to add the `library` argument before library file paths.
Refactor the approach to treat `CMAKE_LINK_LIBRARY_FILE_FLAG` as a
command-line string fragment to add just before the library file path.
This has two advantages:
* `CMAKE_LINK_LIBRARY_FILE_FLAG` now works like `CMAKE_LINK_LIBRARY_FLAG`.
* `CMAKE_LINK_LIBRARY_FILE_FLAG` can now be an attached flag whose value
is the library file path.
Technically this is a change in behavior, but this setting was created
for internal use and should be rarely used outside of CMake itself.
Fixes: #19541
The frontend variant detection logic added by commit 53fbe23f3f (clang:
introduce CMAKE_<lang>_COMPILER_FRONTEND_VARIANT, 2019-02-20,
v3.15.0-rc1~41^2~8) assumes that `clang-cl` only runs on a Windows host.
It is also available on non-Windows hosts. Fix the condition.
Fixes: #19544
Also drop the `CMakeOnly.MajorVersionSelection-PythonInterp_2` test
because some environments now have a plain `python` executable for
Python 3.
Fixes: #19536
The clone step checks out the cloned branch but is always followed by an
explicit checkout of the desired `GIT_TAG`. Tell `git clone` not to
check out.
The NDK build system now uses only a single toolchain in
<ndk>/toolchains/llvm/prebuilt/<host>
Its compilers are always `bin/{clang,clang++}` and its binutils are
always `bin/<triple>-*`. It is a standalone toolchain:
* The Anrdoid API level is specified at the end of `--target=`.
* The standard library may be specified via `-stdlib=`.
* No need to pass system includes or libraries explicitly.
* No need to pass `--sysroot` or `-gcc-toolchain`.
Teach CMake to recognize NDK versions that have a unified
toolchain with its own sysroot and use the above approach.
Fixes: #18739
In commit f7eaa342de (FindMPI: Store imported target link flags as a
list instead of a string, 2019-06-14, v3.15.0-rc2~2^2) we used
`separate_arguments` to parse the extracted link flags and add them to
`INTERFACE_LINK_LIBRARIES`. That property is not meant for link flags
and CMake may de-duplicate them. This is particularly problematic for
flags like `-Wl,-rpath -Wl,/path1 -Wl,-rpath -Wl,/path2`.
In commit 39c572c9c9 (FindMPI: Updated to use INTERFACE_LINK_OPTIONS,
2019-06-24) we moved the parsed flags over to `INTERFACE_LINK_OPTIONS`,
but that may still perform de-duplication. Avoid the parsing and
de-duplication of flags by passing the original string via `SHELL:`
instead.
Fixes: #19516
Since commit d44c0db0b2 (clang: setup correct configuration in gnu mode,
2019-02-20, v3.15.0-rc1~41^2~5) we support the GNU-like Clang that
targets the MSVC ABI. However, Clang cannot compile with the MSVC
standard library unless it runs in a mode aware of C++14 (since MSVC
itself does not even have a lower mode). When `CMAKE_CXX_STANDARD` is
set to 98 or 11, use C++14 anyway.
Since Clang's default mode is aware of C++14, another option is to not
add any flags for 98 or 11. However, if a future Clang version ever
defaults to a higher C++ standard, setting the standard to 98 or 11
should at least not use a mode higher than 14.
Also revert test updates from commit 4819ff9647 (Tests: fix failures
with gnu mode clang on windows, 2019-03-21, v3.15.0-rc1~41^2~3) that
were meant to work around the standard selection problem.
Fixes: #19496
Since VS 2019, the v141 toolset redistributables can be found in
either the VS 2019 or VS 2017 install directory. Update the logic
to search multiple versions of VS.
Fixes: #19488
Fix the toolset v143 check from commit 33ee779330 (IRSL: Fix discovery
of VS 2019 v142 toolset redistributables, 2019-04-03, v3.14.2~6^2) to
check the correct variable.
The singular name `CPACK_INSTALL_SCRIPT` has existed but was not linked
from the CPack documentation. Also, it supported multiple values and
should have had a plural name. Add a plural-named alternative now.
If both `CPACK_INSTALL_SCRIPTS` and `CPACK_INSTALL_SCRIPT` are set then
ignore the latter with a warning.
Signed-off-by: Alex Turbov <i.zaufi@gmail.com>
Define `PROTOBUF_USE_DLLS` on Windows when linking against dynamic
protobuf libraries so that we import symbols from them.
We use the condition `MSVC` to enable this because that is what
the upstream buildsystem uses.
