GCC 8.1.0 now gives an error if `strncpy` is called with a bound
depending on the length of the source argument. Replace `strncpy` with
`strcpy` as the length is known a priori.
Fixes: #18038
Suppress AUTOMOC and AUTOUIC on files generated by Qt4 wrapping macros;
particularly, those generated by `qt4_wrap_cpp`, `qt4_wrap_ui`, and
`qt4_add_resources`. None of these should need AUTOMOC or AUTOUIC
treatment, and CMP0071 makes it important to mark this explicitly.
Our custom command generation logic assumes that all command lines have
at least `argv0`. In `add_custom_{command,target}` we already check
that at least a `COMMAND` was given, but using `COMMAND_EXPAND_LISTS` in
combination with a generator expression that expands to an empty string
may produce an empty command line. In this case simply add an empty
string as a command to maintain our internal invariant.
Fixes: #17993
In commit v3.11.0-rc1~433^2~1 (Add support for IMPORTED GLOBAL targets
to be aliased, 2017-09-14) we accidentally dropped the error on calling
`add_library` to alias an imported target that is not globally visible.
The `add_executable` command's equivalent check was properly updated.
Restore the check in `add_library` with the same update. Also fix the
test case accordingly.
Fixes: #17982
Update `mpi_python##` and `numpy##` component dependencies to honor
python version suffixes on components named by the caller. Although
upstream Boost did not add version suffixes prior to version 1.67, it is
commonly done by distros. Honor suffixes specified by project code.
Projects must take responsibility for naming distro-specific component
suffixes for versions prior to 1.67.
Fixes: #17892, #17970
Revert commit v3.11.0-rc1~274^2 (FindCUDA: Add cublas device library to
separable compilation, 2017-11-03). It breaks targets that do not link
to cublas. Another solution will be needed to solve the original
problem in a more compatible way.
Fixes: #17965
Upstream libuv commits:
* node-v0.6.0~28 (linux: use ioctl(FIONBIO) to set O_NONBLOCK, saves a syscall, 2011-10-29)
* v1.11.0~11 (unix: use async-signal safe functions between fork and exec, 2016-12-12)
left an asymmetry in the way O_NONBLOCK is set and cleared. Normally
ioctl/FIONBIO is used for both. However, uv_spawn uses fcntl/O_NONBLOCK
to clear O_NONBLOCK between fork and exec. This fails on Linux/sparc64
where setting via ioctl/FIONBIO actually sets two bits (in O_NDELAY)
that cause clearing via fcntl/O_NONBLOCK to be silently ignored (though
clearing via ioctl/FIONBIO or fcntl/O_NDELAY works).
Since CMake commit v3.11.0-rc1~117^2 (CTest: Re-implement test process
handling using libuv, 2017-12-10), CTest uses libuv. On Linux/sparc64
child processes have been started with non-blocking output pipes. This
can lead to write errors or lost output from children not prepared to
deal with `EAGAIN` on stdout or stderr.
Fix this for now by switching libuv back to fcntl/O_NONBLOCK to set and
clear O_NONBLOCK when compiled on Linux/sparc64.
LibUV-Issue: 1830
Fixes: #17941
In some environments the linker produces warnings like
warning: directory not found for option
warning: object file compiled with -mlong-branch ...
These do not affect the availability of C++ features we're checking,
so filter them out.
Fixes: #17850, #17947
Internally we mark `file(GENERATE)` outputs as `GENERATED` in order
to tell custom command dependency tracing logic not to expect the
files to exist on disk yet. This is because we do not generate the
files until after that tracing is done.
The Ninja generator also interprets the `GENERATED` property to mean
that it is expected that some build rule will generate the file if
another build rule depends on it. If the generator does not know of a
custom command that generates the file then it adds an empty one so that
the `ninja` build tool does not complain about a dependency on a file
that does not exist and has no rule to generate it. However, this step
is not necessary for `file(GENERATE)` outputs because there is no build
rule to generate them and they will exist before `ninja` runs.
Add an additional `__CMAKE_GENERATED_BY_CMAKE` property internally to
tell the Ninja generator that a `GENERATED` file will exist before the
build starts and is not expected to have a build rule producing it.
Fixes: #17942
Since commit v3.11.0-rc1~177^2 (FindBLAS: optionally query pkg-config
for a library, 2017-12-15) the `BLAS_LIBRARIES` result variable may
incorrectly contain the name of an imported target. Instead store the
list of libraries in the variable. Unfortunately pkg_check_modules does
not provide a way to get this so we need to use a (temporary) hack of
reading `INTERFACE_LINK_LIBRARIES` from the interface library target.
Fixes: #17934
The change in commit v3.11.0-rc1~480^2 (UseJava: add_jar OUTPUT_DIR
option used only for jar generation, 2017-10-12) added code of the form
`file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR})`. This exposed an existing
bug in `CMAKE_DISABLE_SOURCE_CHANGES` in which it does not recognize
that the top of the build tree itself is in the build tree. Fix that
now.
Fixes: #17933
Previously, only existence of `mfc${v}.dll` and `mfc${v}d.dll` variants
was checked and it was assumed that the managed variants `mfcm*.dll`
also existed. This assumption doesn't hold with Visual Studio 2017.
Check each file separately.
Fixes: #17913
The change in commit v3.11.0-rc1~334^2 (FindOpenMP: Use NO_DEFAULT_PATH
where appropriate, 2017-11-15) broke partial support for Intel on Windows.
Since `OpenMP_${LANG}_IMPLICIT_LINK_DIRS` is empty for this compiler
the `find_library` call without `NO_DEFAULT_PATH` worked accidentally
in environments with the needed libraries in the search path already.
Fix support for Intel on Windows by simply removing our explicit search
for the `libiomp5md` library. In cases that it is needed, the compiler
already inserts metadata in `.obj` files to tell the MSVC linker to use
the library.
Suggested-by: Christian Pfeiffer <cpfeiffer@live.de>
Fixes: #17910
Extend the fix in commit v3.9.6~1^2 (Restore exclusion of "gcc_eh" from
implicit link libraries, 2017-11-07) to also exclude `gcc_eh` libraries
referenced by absolute path to the library file.
Issue: #17436
Since commit v3.11.0-rc1~467^2 (VS,Xcode: Add CMakeLists.txt sources
without mutating targets, 2017-10-18) we do not add `CMakeLists.txt` to
target sources but instead generate references to them directly. This
broke projects that explicitly specify their `CMakeLists.txt` file as a
source file because the explicit entry is no longer consolidated with
the generated one.
Teach the relevant generators to avoid duplicating `CMakeLists.txt`
source references and add test cases.
Fixes: #17828
