Refactoring in commit v3.6.0-rc1~72^2 (HDF5: Rework component searching
to correctly find HL for all bindings, 2016-05-12) accidentally dropped
the name `hdf5hl_fortran` from the list of library names and replaced it
with `hdf5_hl_fortran`. IIUC the latter name is when HDF5 is built with
CMake and the former name is for other build systems. Since this is the
non-CMake code path, user the former name.
Closes: #16233
Since commit v3.6.0-rc1~85^2 (HDF5: Refactor the use of compiler
wrappers, 2016-04-01) we have additional code paths that find HDF5 and
suppress the original search logic. Report HDF5_IS_PARALLEL from these
other code paths too.
Closes: #16257
The mechanical conversion in commit 5d0d980d (Use string(APPEND) in
Modules, 2016-07-28) accidentally introduced use of
string(APPEND ... PARENT_SCOPE)
Split that into the string(APPEND) and set(PARENT_SCOPE) pieces.
Added a counter as a directory property that gets incremented every time one
of the cuda_compile* macros is called. The value of this counter is then added
to the phony target name passed to CUDA_WRAP_SRCS. This ensures that every call
to one of these macros has its own unique intermediate output directory.
The macros CUDA_COMPILE, CUDA_COMPILE_PTX, CUDA_COMPILE_FATBIN, and
CUDA_COMPILE_CUBIN were broken by commit 7ded655 (FindCUDA: Take NVCC
include directories from target properties, 2016-08-16). This bug is
due to the fact that all of these macros call CUDA_WRAP_SRCS with a
target name that's not an actual target, causing the new generator
expressions to fail.
Fix the bug by changing these macros to pass "PHONY" to CUDA_WRAP_SRCS.
Now, when CUDA_WRAP_SRCS sees "PHONY", it falls back to the old behavior
of populating the include directories and compile definitions from
directory properties, instead of using target generator expressions.
Since OpenSSL 1.1.0, Windows binaries are libcrypto and libssl instead of
the old names libeay32 and ssleay32.
When using MSVC, FindOpenSSL was searching for the old lib names only so
this add the new names to be able to find OpenSSL 1.1.0 libraries.
For example, the files in lib directory of OpenSSL 1.1.0 Win64 :
- libcrypto.lib
- libssl.lib
- VC/libcrypto64MD.lib
- VC/libcrypto64MDd.lib
- VC/libcrypto64MT.lib
- VC/libcrypto64MTd.lib
- VC/libssl64MD.lib
- VC/libssl64MDd.lib
- VC/libssl64MT.lib
- VC/libssl64MTd.lib
32 bits OpenSSL has the same files with "32" instead of "64" for files in
VC directory.
MinGW still works and use lib/libcrypto.lib and lib/libssl.lib.
This patch also add libssl and libcrypto for other windows compilers too (like
Intel).
Add Visual Studio version number (supported: VS2008 to VS2015) to
WX_LIB_DIR_PREFIX (old: vc / vc_x64; new: vc120 / vc120_x64).
Patch-by: Hannes Grobler (Johnny_xy on gitlab.kitware.com)
7b637ebd Android: Add `ANDROID` variable to indicate the target
c2f561e5 Android: Add test cases covering use of the NDK and standalone toolchains
6b84df8d Help: Document cross compiling for Android
d7d40830 Android: Select the STL type for NDK builds
b22294bc Android: Populate compiler flags for current ABI
b6a3102a Android: Add a CMAKE_BUILD_TYPE default
d1e3cec2 Android: Add Clang -target option for current ABI
504db72d Android: Add placeholders for compiler/abi-specific settings
fa632578 Android: Avoid interfering with common pre-existing toolchain files
6299693f Android: Search for NDK and standalone toolchain in more places
29b51379 Android: Detect and save a standalone toolchain without the NDK
7d9b49fb Android: Detect settings from the CMAKE_SYSROOT if it is set
4389664a Android: Detect and save a toolchain from the NDK
328191f6 Android: Set CMAKE_SYSROOT automatically
9e032304 Android: Detect and save the architecture, ABI, and processor
fde59c4d Android: Detect and save the API level
...
Populate standard include directories and link libraries for the
platform. Select the STL corresponding to CMAKE_ANDROID_STL_TYPE and
matching the current ABI and toolchain to be used. Refer to the NDK
sources/cxx-stl/*/Android.mk files for the needed file locations.
Fixes issue where include directories specified on the target are
not passed on to NVCC. This includes both target_include_directories()
as well as include directories added by dependency chaining.
Closes: #14201
Add a new SOURCE_SUBDIR option to ExternalProject_Add that allows
specifying the location of the CMakeLists.txt to use as the project root
relative to the SOURCE_DIR.
This is helpful for projects that have unusual layouts, or projects that
provide both a superbuild and project-only build depending on which
CMakeLists.txt is used.
Fixes: #15118
1aa5c1be FindCUDA: Fix missing librt on Linux when using static cuda runtime.
aab1f6e9 FindCUDA: Restore default behavior of CUDA_USE_STATIC_CUDA_RUNTIME
Android NDK builds are always `debug` or `release`. We may populate
flags for these configurations that are needed to produce compatible
binaries. Ensure they are used by default.
The Android NDK source repository at
https://android.googlesource.com/platform/ndk.git
has `<ndk>/build/core/toolchains/*/setup.mk` files that store tables of
information for their build system. Add an equivalent file for each
compiler/abi combination.
Commonly used Android toolchain files that pre-date CMake upstream
support may need to be updated to work with our new functionality.
They typically set CMAKE_SYSTEM_VERSION to 1, so detect that and
skip our upstream Android settings. When such toolchain files are
updated to account for our upstream support, they can then set
CMAKE_SYSTEM_VERSION to a valid Android API and get new behavior.
Commonly used Android toolchain files that pre-date CMake upstream
support use a few environment and CMake variables as search locations.
Use them too to aid transition.
Compute CMAKE_SYSROOT automatically for the current API and architecture
selection. This causes the --sysroot option to be passed to GNU and
Clang compilers.
Store the Android API level in CMAKE_SYSTEM_VERSION. If it is not
provided by the user, initialize it from CMAKE_ANDROID_API or fall back
to finding the latest available in the NDK.
Support for NVIDIA Nsight Tegra Visual Studio Edition was previously
implemented in the CMake VS IDE generators. Avoid interfering with
that functionality for now. Later we may try to integrate this.
Provide a way for Platform/<os>-Determine-<lang>.cmake modules to save
platform-specific information about the compiler in the configured
CMake<lang>Compiler.cmake modules.
Once CMAKE_SYSTEM_NAME is known, load a platform-specific
Platform/<os>-Determine
module in order to enable custom determination of the other settings
needed for the CMakeSystem module (e.g. CMAKE_SYSTEM_PROCESSOR). Also
add a hook in Modules/CMakeSystem.cmake.in to allow platform-specific
information to be saved.