- 11 May, 2018 2 commits
-
-
-
Fixes: #17727
-
- 10 May, 2018 2 commits
-
-
-
Brad King authored
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
-
- 09 May, 2018 2 commits
-
-
-
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
-
- 08 May, 2018 4 commits
-
-
Brad King authored
-
-
-
-
- 07 May, 2018 3 commits
-
-
- 02 May, 2018 2 commits
-
-
-
Brad King authored
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
-
- 30 Apr, 2018 2 commits
-
-
-
Brad King authored
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
-
- 27 Apr, 2018 2 commits
-
-
- 26 Apr, 2018 2 commits
-
-
-
Brad King authored
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
-
- 25 Apr, 2018 2 commits
-
-
-
* new version format * new registry layout on Windows Fixes: #17938
-
- 24 Apr, 2018 5 commits
-
-
-
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
-
_props is never used, it was a leftover from a development step.
-
-
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
-
- 18 Apr, 2018 2 commits
-
-
-
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
-
- 17 Apr, 2018 3 commits
-
-
Brad King authored
-
-
-
- 16 Apr, 2018 6 commits
-
-
-
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
-
-
-
-
CMake 3.11 now uses `uv_translate_sys_error` introduced in LibUV 1.10.
-
- 13 Apr, 2018 1 commit
-
-
