efed6468 fix a load of include-what-you-use violations
bd3d0eaf cmCTest: don't redefine cout and cerr
3838a0d5 make sure to include cmConfigure.h before cmStandardIncludes.h
54140848 Tests/CMakeLib: include what you use
3f9c4cdf Tests/CMakeLib: use cmsys::ifstream
The definitions have been introduced to ensure that cout and cerr are
not used in certain files. However, this limitation does not apply to
all source files that require cmCTest.h to be included. Furthermore,
the definitions cause side effects depending on the include order. In
total, the definitions do more harm than good. Remove them.
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.