Clang scan-build warns in some expansions of RB_GENERATE_STATIC
that it has a "Dereference of null pointer". It also warns that
"The left operand of '==' is a garbage value" strangely. Simply
suppress these since this is third-party code anyway.
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 commit v3.5.0-rc1~58^2 (install: Allow generator expressions in
DIRECTORY, 2016-01-12) we accidentally treat leading generator
expressions as relative paths even though they may evaluate to absolute
paths. Defer the conversion to an absolute path until after evaluation.
39ac889d cmake: Add trivial usage of libuv
7cf369fe Do not build libuv on HP-UX
075cae51 Do not build libuv on SPARC
9a53af40 Do not build libuv on Cygwin
219f7411 Do not build libuv on Mac OS X 10.4 and lower
8a5beef3 Add option to build CMake against a system libuv
e56aa462 FindLibUV: Add module to find libuv package
551d5aed libuv: Fix unused variable warning in uv_loop_close
f4f8074b libuv: Avoid including macOS CoreServices header globally
a63aaaed libuv: Always include our own header first
9130b53a libuv: Conditionally declare Windows APIs for VS 2008 and below
b52afa46 libuv: Fix anonymous union syntax
05dbc204 libuv: Fix Windows API function typedef syntax
75139374 libuv: Install LICENSE file with CMake documentation
95dcc4e4 libuv: Disable warnings to avoid changing 3rd party code
13b7e758 libuv: Build the library within CMake
...
Add it to a private source directory that is not installed so that we
can use it for building CMake itself. This will allow it to mature
before being distributed publicly.